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VALIDATION  OF  A  PROTOTYPE  HANDBOOK  OF  DESIGN  GUIDELINES 
FOR  USER  TRANSACTIONS  WITH  BATTLEFIELD  AUTOMATED  SYSTEMS 
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To  develop  a  methodology  that,  provides  a  framework. and  format 
for  a  comprehensive  set  of  human  factors  guidelines  for  the 
design  of  user  transactions  with  battlefield  automated  systems 
for  use  by  human  factors  specialists  and  system  proponents, 
managers  and  developers. 

Procedure: 

To  meet  the  requirements  stated  above,  a  three  phase  research 
program  was  initiated.  Phase  I  was  devoted  to  def inking  human 
factors  requirements  for  battlefield  automated  systems  and 
establishing  a  framework  within  which  guidelines  could  be 
organized.  In  Phase  II,  the  technical  data  base  was  further 
developed  through  search  of  the  military  and  civilian 
literature  related  to  user/operator  transactions  with  automated 
data  processing  systems  and  a  prototype  handbook  of  guidelines 
was  developed.  In  order  to  evaluate  the  utility  and  usability  of 
the  initial. version  of  the  handbook,  it  was  subjected  to  a 
"validation"  process.  To  carryout  this  validation  process,  the 
guidelines  were  applied  against  selected  functions  associated 
witJ^the  Vetronics  and  the  VIDS-DMS  developmental  programs. 

Findings: 

Based  on  the  application  of  the  guidelines  to  the  above 
two  test  cases,  the  format  and  content  of  the  guidelines  are 
conducive  to  their  use  at  different; stages  of  the  system 
development/acquisition  process.  At  very  early  stages  (e.g., 
Vetronics)  review  of  the  Methods  and  Recommendations  sections  in 
particular  provide  good  indications  for  general  design  solutions. 

As  development  progresses,  the  more  detailed  information  specific 
to  design  options  presented  as  Advisory  Comments  become  appropriate. 

Utilization  of  Finding: 

The  metholology,  conceptual  framework  and  format  of  the  guide¬ 
lines  developed  in  the  course  of  this  project  appear  to  provide 
a  productive  approach  to  improving  the  process  of  "technological 
transfer"  of  data  from  human  factors  researchers  to  other  members 
of  system  design  teams  of  battlefield  automated  systems.  Judicious 
application  of  these  guidelines  will  improve  the  effectiveness  of 
the  soldier/machine  interface  of  future  systems  and  will  promote 
the  behavioral  interoperability  of  thfese  systems,  i.e.,  increase 
the  teefe  degree  to  which  skills  and  knowledge  can  be  transferred 
from  one  system  to  another. 
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INTRODUCTION 


This  document  is  one  of  the  products  of  a  project  to  develop 
a  framework  and  format  for  a  handbook  of  human  factors  guidelines 
for  use  by  Army  system  developers  'and  designers,  system  manu¬ 
facturers  and,  particularly,  human  factors  specialists  serving 
as  members  of  design  teams  of  battlefield  automated  systems.  The 
first  phase  of  the  project  developed  a  baseline  of  characteristics 
problems  and  deficiencies  in  the  soldier/machine  interface  of 
existing  systems.  This  baseline  provided  a  foundation  for  the 
second  phase  which  comprised  a  literature  survey  and  preparation’ 
of  a  preliminary  version  of  a  prototype  design  guidelines  hand¬ 
book.  The  object  of  the  third  phase  was  to  evaluate  the  utility 
and  usability  of  the  initial  version  of  the  handbook.  The  present 


document  details  the  results  of  an 


attempt  to  validate  the 


utility  of  the  guidelines  in  a  real  world  context. 

The  objectives  of  the  "validation"  process  were  to  (1)  dem¬ 
onstrate  the  applicability  of  the  guideline,  (2)  obtain  system 
developer  reaction  to  the  guidelines  and  (3)  develop  recommend¬ 
ations  for  revision  of  the  guidelines.  To  carryout  the 
"validation"  process,  the  guidelines  were  applied  against 
•selected  functions  associated  with  the  VIDS-DMS  and  the  Vetronics 
developmental  programs.  Because  of  the  relative  stage  of 
development  of  each  prpgarm,  these  two  applications  afforded 
very  different  contexts  for  guidelines  usage. 

The  first  application  dealt  with  soldier/machine  interface 
issues  associated  with  the  Vetronics  program.  The  Vetronics 
program  underway  under  the  leadership  of  the  US  Army  Tank  and 


Automotive  Command  (TACOM)  has  as  its  object  the  definition  of 
the  system  architecture  required  to  support  the  total  integration 
of  armored  vehicles  electrical/electxonic,  informational  and 
display  systems  and  technology  within  the  context  of  the  AirLand 
Battle  2000  concept.  The  second  application  deait  with  the 

t 

VIDS-DMS  {Vehicle  Integrated  Defence  System  -  Data  Management 
System)  program.  The  purpose  of  this  program  is  to  provide  a 
data  management/display  system  to  coordinate  the  threat  warning 
sensors,  threat  reaction  devices  and  crew  interaction  subsystems 
of  tanks  and  other  armored  vehicles. 

These  two  application  efforts  provided  the  basis  for 
refinement  of  the  format  and  methodology  for-  developing  design 
guidelines  for  user  interactions  with  battlefield  automated 
systems.  These  refinements  have  been  incorporated  into  the 
latest  version  of  a  prototype  handbook  published  under  separate 
cover  as  part  of  this  project. 
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SOLDIER/MACHINE  INTERFACE  ISSUES  IN  THE 
APPLICATION  OF  THE  VETRONICS  CONCEPT 
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INTRODUCTION 


Background  and  Purpose 


The  interim  report  is  a  product  of  Contract  Number  MDA903-82-C-0254 
sponsored  by  the  Army  Research  Institute  for  the  Behavioral  and  Social 
Sciences  (ARI).  The  project  is  entitled  "Validation  of  Prototype  Design 
Handbook  for  User/Operator  Transactions  with  Battlefield  Automated  Systems." 
One  of  the  early  efforts  in  this  project  consisted  of  two  steps: 

1.,  Analyze  design  issues  related  to  the  Soldier-Machine  Interface 
(SMI)  in  the  VEhicle  ElecTRONICS  (Vetronics)  concept. 

2.  Develop  recommended  resolutions  to  a  subset  of  these  issues 
by  applying  appropriate  guidelines  from  the  Prototype  Design 
'Handbook  for  Combat  and  Materiel  Developers.1 


Synectics  developed  the  Prototype  Handbook  under  a  previous  contract  entitled: 
"Development  of  Design  Guidelines  and  Criteria  for  User/Operator  Transactions 
with  Battlefield  Automated  Systems."2 

The  purpose  of  this  report  is  to  describe  activities  and  findings  of  the 
effort  outlined  above.  A  supplemental  report  describes  a  similar  process  for 
a  second  battlefield  automated  system,  the  Data  Management  System  of  the 
Vehicle  Integrated  Defense  System  (VIDS-DMS) .  Both  reports  recapitulate 
earlier  preliminary  versions  and  set  forth  findings  regarding  developer 
feedback  on  the  readability,  interpretability,  validity,  and  applicability 
of  the  guidelines  selected  for  each  system.  Volume  I  of  this  Final  Report 
describes  the  technical  approach  and  rationale  for  demonstrating  the  Handbook 
by  application  to  two  systems;  summarizes  salient  points  related  to  SMI 
analyses  and  developer  feedback;  and  presents  recommendations  for  improving 
the  content  of  the  guidelines  contained  in  the  Handbook.  The  Revised  Prototype 
Handbook  is  published  as  Volume  II  of  this  Final  Report. 


'Parrish,  R.  N. ,  Gates,  J.  L. ,  Munger,  S.  J.,  Grimma,  P.  R. ,  and  Smith,  L.  T. , 
Development  of  Design  Guidelines  and  Guidelines  and  Criteria  for  User/ 
erator  Transactions  with  Battlefield  Automated  Systems.  Phase  II Final 


Volume  II,  Prototype  Design  Handbook  for  Combat  and  Materiel 


Organization  of  the  Report 

Part  1  provides  an  overview  of  the  current  definitions  of  "Vetronics" 
for  the  benefit  of  readers  who  are  unfamiliar  with  the  concept.  Part  2,. 
Analysis  and  General  Findings  describes  the  techniques  used  to  analyze  the 
program's  projected  software  requirements  and  discusses  global  issues  in 
the  design  of  the  soldier/machine  interface.  Part  3,  Projected  Software 
Functions,  addresses  selected  functions  separately,  first  presenting  a 
brief  functional  description  as  inferred  from  available  Vetronics  . 
documentation.  Implications  are  then  derived  for  the  soldier/machine 
interface  and  finally  recommendations  to  resolve  design  issues  are  presented 
Part  4  contains  a  summary  of  design  issues  and  recommendations. 

Overview  of  the  Vetronics  Concept 

The  Army's  Vetronics  concept  is  analagous  to  the  aviation  community's 
Avionics  concept.  That  is,  Vetronics  is  the  application  of  electrical  and 
electronic  technology  and  experience  to  future  ground  combat  vehicles. 
Currently,  Vetronics  applications  appear  to  be  restricted  to  on-board  systems 
however,  later  integration  of  data  transmitted  to  the  vehicle  from  external 
sources  presents  no  insuperable  problems . 

A  Vetronics  Action  Team  (VAT) ,  of  which  ARI  is  a  member,  has  responsi¬ 
bility  for  defining  the  scope  and  requirements  for  Vetronics.  The  VAT 
established  the  following  boundaries  for  its  scope: 

1.  Define  Vetronics  and  identify  those  systems  and  subsystems 
for  which  growth  potential  must  exist  on  board  combat 
vehicles . 

2.  Define  the  system  architecture  required  to  support  the  total 
integration  of  ground  vehicle  electrical/electronic  systems 
and  technology,  as  foreseen  on  the  Integrated  Battlefield. 

The  effort  reported  here  is  concerned  primarily  with  validating  the  prototype 
Handbook  cited  earlier.  However,  it  also  provides  preliminary  assistance 
for  ARI  support  to  TACOM  in  defining  and  resolving  SMI  issues  of  Vetronics — 
the  area  of  ARI's  specific  concern  as  a  VAT' member. 

The  Integrated  Battlefield  concept  integrates  all  Arms/Services  and 
coordinates  a  variety  of  sensor,  intelligence,  tactical,  and  strategic  data 


to  improve  the  exility  of  the  US  and  its  Allies  to  face  and  defeat  large  and 
sophisticated  enemy  forces  with  conventional  weapons.  Vetronics,  which 
constitutes  an  evolving  technological  development  product,  is  a  potential 
bridge  for  effective  employment  of  armored  vehicles  within  the  AirLand  Battle 
concept.  AirLand  Battle  and  AirLand  Battle  2000  are  doctrine  and  tactics  to 
provide  the  US  a  more  versatile,  lethal,  offense-oriented,  mobile  fighting 
force  than  now  exists— and  one  which  has  improved  capacity  for  small  units  to 
function  with  greater  autonomy  them  current  doctrine  permits.  The  AirLand 
Battle  concept  incorporates  lighter  than  current  vehicles  and  forces.  AirLand 
Battle  extends  through  the  1990's;  AirLand  Battle  2000  doctrine  is  to  serve 
well  into  the  21st  Century.  Thus,  the  AirLand  Battle  concepts  are  addressing 
battlefields  and  high  technology  weaponry  over  the  next  three  and  one-half 
decades . 
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ANALYSIS  AND  GENERAL  FINDINGS 


Overview 


Hie  effort  reported  here  parallels,  to  sane  extent,  the  other  effort 
carried  out  for  validation  of  the  Prototype  Handbook  against  the  SMI  of  the 
Vehicle  Integrated  Defense  System  -  Data  Management  System  (VIDS-DMS) .  This 
effort  differs  from  the  earlier  one,  however,  in  that  a  Preliminary  Specifica¬ 
tion3  for  a  Feasibility  Demonstration  Model  of  the  VIDS-DMS  was  available 
from  which  to  interpret  and  project  SMI  issues.  In  the  case  of  Vetronics, 
documentation  has  not  yet  progressed  to  the  stage  of  preliminary  specification 
Bather,  current  Vetronics  data  are  restricted  to  broad  conceptualizations  of 
functions/applications.  Thus,  much  of  the  discussion  in  the  "Projected 
Software  Functions"  section  below  is  necessarily  speculative.  Nonetheless, 
these  speculations  appear  reasonable  in  light  of  information  in  the  sources 
available  for  the  analysis. 

There  were  two  primary  sources  for  the  analysis  of  the  vetronics  concept: 

1.  Hie  Armored  Combat  Vehicle  Technology  Exploitation  Concept 
Plan,  a  briefing  prepared  and  presented  by  the  US  Army's 
Tank- Automotive  Command  ( TACQM)  to  the  Armored  Combat  Vehicle 
Science  and  Technology  (s&T)  Program  Advisory  Council ,  on 

11  February  1982.  This  plan  was  prepared  in  response  to  a 
request  to  TACOM  from  Dr.  Marvin  Lass er.  Director  of  Army 
Research,  to  provide  a  plan  for  involvement  of  ARI  in  TACOM 
technical  base  activities.  It  was  further  requested  that 
this  plan  pursue  products  and  battlefield  automation  in 
tank- automotive  applications. 

2.  Hie  Vetronics  Action  Team  (VAT)  briefing,  prepared  for  and 
presented  to  the  Program  Advisory  Council  for  the  Tank  S&T 
Base  Program,  by  Donald  S.  Sarna,  Chairman,  VAT,  Tank  S&T 
Program,  on  11  February  1982. 

Both  of  the  briefings  address  issues  pertaining  to  the  combat  vehicle  on  the 
integrated  battlefield,  focusing,  of  course,  to  vehicle  electronics — Vetronics 


3Praft  Procurement  Specification:  Vehicle  Integrated  Defense  System  -  Data 
'  Management  System  (VIDS-DMS) .  Warren,  MI:  US  Army  Tank- Automotive  Coanand 


Research  and  Development  Center,  July  1982.  (R- 3760-10279) 


4 


The  above  sources  provided  information  by  which  to  identify  and  then 
delimit  those  aspects  of  the  combat  vehicle  judged  to  be  part  of  the  Vetronics 
concept,  and  which  have  implications  for  the  soldier-machine  interface.  While 
there  is  some  variance  in  terminology  and  construct  between  the  two  informa¬ 
tion  sources,  the  following  list  appears  to  fairly  represent  the  candidate 
aspects  of  the  Vetronics  capability: 

1.  BIFF  (Battlefield  Identification  Friend  or  Foe) 

2.  Combat  Simulation  Training 

3 .  Communi cat i ons 

4.  Diagnostics/Prognostics 

5.  Drive  System  Performance 

6 .  Engine  Control 

7.  GPS  Enhancement ,  Target  Cueing 

8.  Gun  stabilization  and  Fire  Control 

9.  Integrated  Defense  System 

10 .  Maneuver/Navigate 

11.  Mass  Data  Storage 

12.  Off-board  Sensor  Fusion 

13.  On-board  Sensor/Countermeasure  Management 

14.  Platform  Support/Damage  Control  Monitor 

15 .  System  Status 

16.  Tactical  Situation  Display 

Familiarity  with  the  capabilities  of  the  VIDS-DMS,  through  previous 
analysis  of  the  VIDS-DMS  Feasibility  Demonstration  Model,  suggested  that  some 
candidate  aspects  for  Vetronics  are  already  included  in  the  VIDS-DMS.  Of  the 
above  listed  candidate  Vetronics  capabilities,  the  following  appear  to  fit 
this  category: 


1.  Communications.  New  communications  capabilities  are  not 
expected  to  be  an  integral  part  of  Vetronics.  Communication 
status  information  will  be  handled  as  part  of  System  status. 

2.  Routine  and  exception  data  for  Drive  System  Performance, 

Engine  Control,  and  Platform  Support/Damage  Control  Monitor 
will  probably  be  provided  through  System  Status  capabilities. 

3.  On-board  Sensor  Countermeasure  Management  and  GPS  Enhancement, 

Target  Cueing  are  assumed  to  be  handled  by  VIDS-DMS.  The 
Integrated  Defense  System  is  the  VIDS  proper. 

Mass  Data  Storage  was  eliminated  from  consideration  because  it  appears 
to  involve  no  SMI  issues.  The  Gun  Stabilization  and  Fire  Control  Capability 
was  eliminated  because  Vetronics  does  not  appear  to  enhance  current  capabilities 
or  involve  soldier-machine  interface  issues  beyond  simple  status  information 
discussed  as  part  of  System  Status.  Finally,  Off-Board  Sensor  Fusion  was 
eliminated  from  consideration  because,  as  noted  above,  Vetronics  appears  to 
be  restricted  to  within-the-vehicle  capabilities,  and  because  fusion  of  data 
from  sources  external  to  the  vehicle  is  part  of  another  development  concept 
now  identified  as  the  Integrated  Intelligent  Vetronics  (VINT2). 

Thus,  the  following  applications  appear  to  be  the  only  ones  having  viable 
soldier-machine  interface  implications  which  are  specific  to  Vetronics: 

1.  BIFF 

2.  Combat  Simulation  Training 

3.  Diagnostics/Prognostics 

4.  Maneuver /Navigate 

5.  System  Status 

6.  Tactical  Situation  Display 

For  each  of  the  above  identified  candidate  applications,  the  analysis  some¬ 
what  speculatively  delineated  user  requirements  and  derived  SMI  implications. 
This  discussion  addresses  types  of  interactions  likely  to  be  required  and, 
where  possible,  tasks  likely  to  be  imposed  on  the  crew.  Lastly,  recommenda¬ 
tions  were  developed  to  resolve  selected  issues  implied  by  the  analysis,  and 
sections  of  the  Prototype  Handbook  containing  guidance  relevant  to  those 
issues  were  suggested. 
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The  soldier-machine  interface  implications  of  Vetronics  are  concerned 
with  providing  the  combat  vehicle  crew  with  that  information  required  to 
perform  their  tasks.  There  are  three  essential  components  in  the  design  of 
the  Vetronics  soldier-machine  interface: 

1.  Determining  what  information  is  required  under  what  circumstances. 

2.  Limiting  the  information  to  only  that  which  is  required  under 
the  given  circumstances. 

3.  Designing  the  best  data  capture /presentation  parameters,  as 
appropriate  to  the  information  and  usage  characteristics. 

Vetronics  is  the  integrator  of  a  large  number  of  elaborate  data  sets  dealing 
with  such  diverse  types  of  information  as  targets,  vehicle  status,  vehicle 
maneuver  capability,  meteorological  data,  sensor  data — all  of  those  types  of 
information  identified  in  Tables  A-l  through  A-9  in  the  Appendix.  At  this 
stage  of  development  of  Vetronics,  it  seems  appropriate  to  provide  general 
findings  with  respect  to  two  topics: 

1.  The  volume  and  type  of  soldier-machine  interface. 

2.  General  design  implications. 

VOLUME  AND  TYPE  OF  INTERACTION 

In  contrast  with  the  VIDS-DMS,  Vetronics  appears  to  require  a  relatively 
high  interaction  with  the  crew.  Although  much  of  the  data  that  will  be 
provided  through  Vetronics  will  be  entered  automatically  and  not  require  crew 
intervention,  much  of  that  information  will  be  available  to  the  crew  only 
on  demand,  i.e.,  only  through  crew  interaction.  Exceptions  to  this  are  the 
warnings  and  status  data  presented  via  the  Diagnostics/Prognostics  capability. 

Operation  of  Vetronics  in  a  combat  vehicle  which  must  maneuver  across 
the  battlefield  presents  obstacles  to  the  crew's  ability  to  handle  the  volume 
and  varied  types  of  interaction  required.  The  battlefield  will  add  noise  and 
confusion;  combat  will  add  stress  and  the  need  for  quick  response.  Under 
these  conditions  the  crew  will  need  to  access,  review,  and  coordinate  data  in 
the  most  efficient  manner.  There  must  be  no  cause  for  hesitation  in  requesting 
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information,  or  any  ambiguity  in  interpreting  it  when  it  is  presented. 

Vetronics  will  greatly  expand  the  the  crew’s  knowledge  about  the  vehicle, 
the  battlefield,  and  the  battle.  This  expansion  enhances  the  crew's  and  the 
vehicle's  chances  for  survival.  But  improved  suvivability  comes  at  the  price 
of  a  larger  and  more  complicated  crew  workload,  not  a  reduced  and  simplified 
one.  Vetronics  cannot  be  allowed  to  negatively  impact  crew  performance, 
thereby  defeating  its  purpose  of  enhancement  of  combat  operations.  It  must  be 
carefully  integrated  into  the  current  duties  of  the  crew  so  that  all  vehicle 
and  battle-related  actions  are  fluid  and  coordinated. 

GENERAL  DESIGN  IMPLICATIONS 

The  relatively  expansive  data  sets  and  enlarged  crew-vehicle-Vetronics 
interface  that  Vetronics  brings  to  the  combat  vehicle,  impose  some  severe 
design  constraints  on  the  soldier-machine  interface.  Tasks  should  be  struc¬ 
tured  so  that  missions  can  be  accomplished  with  a  minimum  number  of  steps  and 
at  as  minimal  a  difficulty  level  as  possible.  Vetronics  tasks  should  be 
integrated  with  other  crew  responsibilities  on  the  most  logical  and  efficient 
basis  possible.  Tasks  should  conform  as  nearly  as  possible  to  those  already 
within  the  crew's  skill  profile.  The  crew  must  not  be  required  to  master  and 
use  complex  command  languages,  extensive  interactive  procedures,  or  other 
sophisticated  computer  skills. 

Information  to  be  presented  on  displays  must  be  selected  in  accordance 
with  rigid  criteria  of  relevance  and  need,  so  that  all  essential  information — 
but  only  essential  information — reaches  the  crew.  Information  elements  must 
reach  the  crew  at  the  time  and  in  the  sequence  in  which  they  are  needed. 
Presentation  formats  must  be  designed  to  present  that  information  logically, 
in  the  sequence  in  which  it  will  be  used,  and  in  arrangements  on  the  display 
that  facilitate  rapid,  accurate  interpretation  and  understanding.  At  the  same 
time,  input  methods  must  be  kept  as  simple  and  consistent  as  possible,  and  be 
designed  for  rapid  easy  entry,  while  keeping  opportunities  for  crew  members  to 
commit  errors  to  the  absolute  minimum. 

Vetronics  offers  a  most  plausible  and  fortunate  opportunity  for  design 
and  development  of  a  comprehensive  on-board  training  module  with  simulated 
conditions.  This  training  program  should  be  as  functionally  representative 
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of  the  actual  Vetronics  capability  as  is  possible.  Utilization  of  such  a 
training  program  module  could  go  a  long  way  in  overcoming  some  of  the  addi¬ 
tional  workload  imposed  on  the  crew  through  Vetronics.  Design  implications 
for  Vetronics  are  also  applicable  to  the  design  of  the  training  module. 

Issues  discussed  here  could  and  should  be  much  more  thoroughly  explored 
so  that  the  soldier-machine  interface  issues  of  Vetronics  are  attended  to  in 
a  most  positive  fashion.  These  SMI  issues  should  be  given  careful  and  contin¬ 
uous  attention  throughout  the  development  of  Vetronics,  beginning  as  early  in 
the  design  process  as  possible.  While  the  following  sections  discuss  some 
SMI  issues,  these  analyses  have  been  based  on  preliminary  information.  This 
document  can  serve  therefore,  only  as  a  starting  point  for  the  more  extensive 
exploration  of  the  soldier-machine  interface  that  is  essential  to  assure  the 
greatest  efficiency  and  effectiveness  of  Vetronics. 


Maneuver/Navi gate 


INFERRED  FUNCTIONAL  DESCRIPTION 

There  are  three  roles  or  situations  for  the  combat  vehicle  to  be  considered 
in  the  Vetronics  capability  for  mane uve ring/navigating  with  respect  to  engage¬ 
ment  between  two  antagonistic  forces.  One  of  these  involves  the  movement  of 
forces,  or  the  positioning  of  capabilities,  in  preparation  for  combat.  A 
second  is  actual  engagement  with  the  enemy  or  threat.  And  a  third  involves 
avoidance  of  the  enemy  or  threat  when  the  outcome  will  be  negative,  hazardous, 
or  militarily  unjustified.  Each  of  these  roles  depends  upon  the  crew's  abil¬ 
ity  to  maneuver/navigate  the  vehicle.  The  crew/vehicle  capability  to  maneuver 
in  a  non-combat  situation  is  not  substantially  different  than  the  battle  con¬ 
dition,  except  that  it  occurs  in  a  non-threatening  environment. 

The  crew/vehicle  function  of  maneuver/navigate  is  a  continuing  process 
and  dependent  upon  the  availability  and  utility  of  identified  information 
parameters.  Consideration  of  the  Vetronics  maneuver/navigate  capability  pro¬ 
vides  a  set  of  those  information  items  required  by  the  crew  to  perform  a 
series  of  tasks,  the  composite  of  which  forms  the  function  of  maneuver/navigate. 
The  maneuver/navigate  capability  is  discussed  in  terms  of  information  require¬ 
ments  ,  information  sources ,  and  crew  tasks . 


Information  Requirements 

The  requisite  information  for  crew/vehicle  performance  of  the  Vetronics 
navigate/maneuver  function  consists  of : 

1.  Terrain/terrain  relief 

2.  Terrain  type /condition 

3.  CVn  position 

4.  Objective/destination 

5 .  Battle  plan 

6.  Attitude 
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7 .  Environment 


8.  Engine /drive  status 

9.  Electrical  status 

10.  Bearing 

11.  Hostile  forces 

12.  Tank  capabilities/characteristics 

Each  of  the  information  items  is  described  below. 

Terrain/terrain  relief.  Terrain/terrain  relief  information  describes  the 
surface  features  of  a  geographical  area  and  is  generally  provided  in  a  topo¬ 
graphic  manner  through  maps.  Zn  a  combat  vehicle,  this  information  is  a 
candidate  for  presentation  graphically  through  the  capability  of  the  Tactical 
Situation  Display.  The  crew  uses  the  information  to  determine  a  route  to  an 
objective/destination  by  matching  the  vehicle's  capabilities  against  the 
demands  imposed  on  the  vehicle  by  the  terrain. 

Terrain  type/condition.  Terrain  type/condition  information  concerns  surface 
features  of  a  geographical  area  and  can  be  presented  graphically  on  the 
Tactical  Situation  Display.  The  information  covers  man-made  items  (e.g., 
bridges,  roads)  and  includes  identif ication  of  areas  that  offer  restrictions 
to  an  armored  vehicle's  progress  (sand,  marsh,  forest,  mud,  etc.).  The  crew 
uses  this  information  to  determine  routes  or  alternate  routes  to  an  objective/ 
destination  by  matching  vehicle  capabilities  against  terrain  features. 

Own  position.  Own  position  information  consists  of  the  latitude  and  longitude 
or  map  coordinates  of  a  combat  vehicle's  present  position.  The  crew  uses 
this  information  for  vehicle  maneuvering  and  scheduling.  It  is  candidate 
information  to  be  presented  by  graphic  representation  on  the  Tactical  Situ¬ 
ation  Display.  To  date,  a  crew  cannot  expect  to  have  real-time  updates  of 
own  position  once  a  mission  is  underway.  (NOTE:  Such  capability  is  planned  via 
the  Position  Locating  Report  System  (PLRS) .  PLRS  is  intended  to  aid  the 
maneuver/navigate  capability  by  presenting  real-time  own  position  information 
on  demand  by  the  crew.) 

Objective/destination .  Objective/destination  information  represents  a  decision 
made  by  an  authority  to  approach  or  leave  an  area  or  force.  The  objective/ 


destination  can  be  represented  graphically  through  the  Tactical  Situation 
Display.  The  crew  uses  this  information  for  route  planning. 

Battle  plan.  Battle  plan  information  is  used  for  maneuvering/navigating  as 
it  affects  the  positioning,  deployment,  or  utilization  of  the  combat  vehicle 
as  it  approaches  its  objective.  The  crew  maneuvers/navigates  the  vehicle  to 
satisfy  the  requirements  of  the  battle  plan. 

Attitude .  Attitude  information  concerns  the  combat  vehicle's  physical  orien¬ 
tation  at  any  given  time.  Useful  attitude  information  consists  of  roll,  pitch, 
and  occasionally,  yaw.  The  information  can  be  presented  digitially,  graphically 
or  as  an  analog.  The  crew  uses  this  information  to  determine  how  close  their 
vehicle  is  to  safety  limits  and  to  make  decisions  as  to  maneuvering.  This 
information  is  presented  through  the  System  Status  capability. 

Environment.  Environment  data  describe  the  natural  environment  surrounding 
the  combat  vehicle's  position.  Data  include  rain,  smoke,  fog,  ice,  snow, 
outside  temperature,  and  remaining  light.  Changes  in  the  environment  during 
the  conduct  of  a  mission  can  adversely  affect  the  combat  vehicle’s  mobility. 

This  information  can  be  presented  digitally  or  as  an  analog.  Crews  will  use 
environment  data  to  make  decisions  affecting  battle  plans,  available  routes, 
and  maneuvers. 

Engine /drive  status.  The  engine/drive  status  information  describes  the  status 
of  seme  of  the  combat  vehicle’s  motive  systems.  Included  are  engine  oil  temper¬ 
ature,  pressure,  and  level.  Also  included  are  engine  power  or  RPM,  exhaust 
gas  tenperature ,  remaining  fuel/fuel  consumption,  and  transmission  oil  temper¬ 
ature.  In  the  event  that  systems  are  installed  that  utilize  engine  bleed  air 
or  hydraulic  pumps,  then  pressure  information  from  these  systems  will  be  re¬ 
quired.  This  information  can  be  presented  digitally,  as  an  analog,  or  graphi¬ 
cally  through  the  System  Status  capability.  Impending  failure  and  trouble 
indications  and  accompanying  information  are  presented  via  the  Vetronics 
Diagnostics/Prognostics  capability.  The  crew  uses  this  information  to  make 
decisions  regarding  available  routes,  changes  in  plans,  and  to  make  repairs. 

Electrical  status.  Electrical  status  information  is  concerned  with  the 
operation  of  the  engine-driven  alternator /generator  or  other  power  source  for 
the  combat  vehicle's  electrically  pewered  devices.  In  the  event  of  a  failure 
in  the  engine-driven  altemator/generator  or  primary  generating  device,  the 


crew  will  need  to  make  decisions  based  on  the  output  and  life  expectancy  of 
the  auxiliary  power  source.  Should  only  the  battery  remain,  the  crew  will 
need  to  know  that  also.  Degraded  range  or  operability  may  cause  the  crew  to 
select  different  routes  or  make  repairs.  The  System  Status  capability  provides 
this  status  information. 

Compass  bearing.  The  compass  bearing  describes,  in  degrees,  the  combat  vehicle* 
present  heading.  The  information  can  be  provided  digitally,  as  an  analog,  or 
graphically  on  the  Tactical  Situation  Display.  The  crew  uses  this  information 
in  determining  their  present  position  for  navigating  and  maneuvering.  This 
information  may  be  available  via  the  System  Status  capability  in  lieu  of  or 
in  addition  to  the  Tactical  Situation  Display. 

Hostile  forces.  Hostile  forces  information  describes  the  threats  to  and 
objectives  of  the  combat  vehicle .  The  data  can  be  provided  digitially  or 
graphically  on  the  Tactical  Information  Display.  Information  consists  of 
known  hostile  sensors  and  weapons  locations  and  of  mobile  forces'  last  known 
positions.  This  information  will  be  available  to  the  crew  while  the  vehicle 
is  in  garrison  (pre-attack  staging).  Once  a  mission  is  in  progress,  data 
received  through  the  VIDS-DMS  will  be  available  to  the  crew.  The  information 
available  to  the  crew  consists  of  warnings  as  to  the  detection  of  hostile 
scanning  by  infra-red,  laser,  or  radar  frequencies,  as  well  as  optical  and 
acoustic  detectors.  The  crew  will  use  this  information  for  immediate  defen¬ 
sive  or  offensive  maneuvers  as  well  as  alternate  route  planning. 

Vehicle  capabilities/characteristics .  Information  about  vehicle  capabilities 
and  characteristics  is  largely  acquired  by  the  crew  through  training  and  ejqper- 
ience.  For  example,  routes  are  planned  by  matching  the  terrain  encountered 
against  the  vehicle's  terrain  crossing  capabilities.  Destinations  and  routes 
are  planned  using  knowledge  of  the  vehicle's  range  and  speed  over  different 
terrains.  Maneuvers  are  undertaken  using  the  crew’s  knowledge  of  the  vehicle's 
turning  radius  and  stability.  Information  to  support  the  crew  while  planning 
maneuvers  and  navigation  can  be  provided.  However,  this  information  is  best 
limited  to  information  already  discussed:  vehicle  speed,  remaining  fuel, 
bearing,  attitude,  engine/drive  status,  etc.  The  crew's  familiarization  of  the 
combat  vehicle's  capabilities  is,  to  date,  expected  to  be  enhanced  by  but  not 
dependent  upon  information  provided  through  the  Tactical  Situation  Display. 


Information  Sources 


As  indicated  in  the  descriptions  of  the  information  requirements,  the 
information  comes  from  a  variety  of  sources,  including: 

1.  Internal  storage 

2.  Crew  input/knowledge 

3.  Derived  information 

4.  Internal  sensors/instrumentation 

5.  VIDS-DMS  sensors 

6.  PLRS ,  when  available 

Combat  scenarios,  projecting  future  engagements,  are  one  source  of  data 
which  could  be  loaded  into  the  vehicle  as  a  basis  for  the  maneuver/navigate 
capability.  These  combat  scenarios  would  employ  plausible  battle  plans  and 
strategies  and  deal  with  map,  terrain,  hostile  forces,  BIFF  data,  etc.,  in 
an  attempt  to  provide  as  realistic  parameters  of  the  combat  situation  as 
practicable.  The  greater  the  amount  of  information  that  can  be  provided 
through  internal  storage ,  and  made  available  to  the  crew  via  the  SMI ,  the 
lesser  is  the  demand  on  crew  skills  and  memory. 

Crew  Tasks 

The  crew's  portion  of  the  maneuver/navigate  capability  makes  use  of  the 
available  information  to  perform  the  following  functions: 

1.  Route  availability /planning 

2.  Maneuvering 

3.  Scheduling 

4.  Threat  assessment 

5.  Target  selection 

During  pre-attack  staging,  the  crew  loads  the  most  recent/best  information 
available  concerning  routes,  threats,  schedules,  plans ,  strategies,  etc. 

Once  underway,  information  will  be  updated  through  on-board  sensor  and  status 
data  where  possible  and,  where  necessary,  through  crew  observation,  communication 


with  other  combat  vehicle  crews,  and  through  the  VIDS-DMS. 

DERIVED  SOLDIER-MACHINE  INTERFACE  IMPLICATIONS 

One  conclusion  that  can  be  drawn  from  the  preceding  discussion  is  that 
the  maneuver/navigate  capability  requires  substantial  support  in  terms  of 
information  both  before  and  during  a  mission.  Also,  the  requirements  on  the 
information  are  varied.  Some  information  has  to  be  especially  accurate,  some 
precise  within  a  range  of  values,  some  current  to  a  short  time  standard,  etc. 

An  additional  conclusion  concerns  the  differing  display  requirements  for  the 
task  support  information.  Some  data  will  require  a  tailored  display  screen 
and  format  for  maximum  effectiveness,  while  other  data  can  be  provided  through 
more  traditional  or  conventional  instrumentation.  A  further  implication  con¬ 
cerns  the  duration  of  the  display  of  information.  Requirements  vary  from  a 
near  continuous  display,  to  an  "as  required"  display,  to  an  "exception  basis 
only"  display. 

The  initial  evaluation  of  the  information  requirements  to  support  maneuver/ 
navigate  tasks  suggests  an  information  display  device  or  system  of  considerable 
capability.  The  interface  area  must  be  large  enough  to  display  terrain  data 
over  a  geographical  area  suitable  in  size  for  combat  purposes,  and  offer 
resolution  and  contrast  in  detail  to  a  level  usable  by  the  crew  in  decision 
making.  Additionally,  the  interface  must  provide  status/instrument/sensor 
data,  probably  through  the  display,  either  continuously,  on  demand,  or  by 
exception.  The  possibility  of  supplying  real-time  position  locating  infor¬ 
mation  through  PLRS  may  become  a  reality  for  the  Combat  Vehicle .  This  infor¬ 
mation  will  be  provided  to  the  crew  through  the  SMI  and,  ideally,  graphically 
through  the  Tactical  Situation  Display.  While  a  current  SMI  does  not  need  to 
attend  to  PLRS  data,  the  SMI  should  be  prepared  by  design  for  that  eventuality. 

The  crew  will  also  need  to  instruct  the  Vetronics  system,  through  the  SMI, 
to  display  "on  demand"  data.  This  data  may  be  engine  instrumentation  not 
ordinarily  displayed,  an  expanded  scale  of  terrain  data,  updated  information 
from  the  VIDS-DMS,  or  mission  information  from  additional  sources.  The  crew 
will  therefore  need  capability  to  input  instructions  to  Vetronics  through  the 
SMI.  Given  the  conditions  inside  a  combat  vehicle  engaged  in  action,  the 
input  mechanisms  and  instructions  must  be  simple  in  demand  and  limited  in 
number. 


RECOMMENDATIONS 


1.  Sections  of  the  Prototype  Handbook  relating  to  display/ 
interface  issues  of  the  maneuver/navigate  task  are: 

1.1  Alphanumeric  Control  Methods 

1.2  Graphics  Control  Methods 

2.1  Alphanumeric  Displays 

2.2  Graphics  Displays 

2.3  Selective  Highlighting 

3.2  Unburdening  of  Input 

4.2  Composition  Aids  for  Graphics  Displays 

5 . 1  Query  Method 

6.1  Symbols  and  Symbol  Sets 

7.1  Error  Feedback 

7.2  Error  Correction  and  Recovery 

2.  Allow  sufficient  range  in  the  display  of  terrain  data  so  that 
both  the  objective  and  crew's  present  position  are  simultane¬ 
ously  displayed. 

3.  Provide  sufficient  terrain  relief  and  artifact  features  in 
the  topographic  display  to  allow  the  crew  to  make  maneuver/ 
navigate  decisions. 

4.  Display  compass  heading  information  digitally  and  continuously. 

5.  Display  updated  status  information  (threat,  open  or  closed 
bridges,  open  or  closed  roads,  etc.)  through  the  terrain  dis¬ 
play  as  blinking  graphics  characters.  Require  the  crew  to 
acknowledge  these  updates  through  push-push  switches. 

6.  Provide  terrain/terrain  relief  data  on  the  topographic  display 
with  enhancements  to  depict  such  features  as  routes  negotiable 
by  combat  vehicles;  bridges;  fordable,  non-fordable  streams ; 
and  "slow  footing"  surfaces. 


System  Status 


INFERRED  FUNCTIONAL  DESCRIPTION 

This  capability  will  check  all  on-board  systems  and  advise  the  crew  of 
their  status .  Some  of  these  indicators  will  interact  with  the  Diagnostic/ 
Prognostic  capabilities  for  the  vehicle's  operation.  The  System  Status  capa 
bility  differs  from  the  Diagnostic/Prognostic  capability  in  that  (1)  it  is 
accessed  voluntarily  by  the  crew  rather  than  presented  automatically,  as  is 
the  case  with  the  Diagnostic/Prognostic  capability  and  (2)  it  reacts  across 
all  status  dimensions,  providing  current  information  regarding  normal 
as  well  as  critical  status  information.  It  also  interacts  with  the  Tactical 
Situation  Display  capability  in  that  it  reports  on  the  status  of  some  of  the 
data  capture  capabilities  that  report  through  the  Tactical  Situation  Display 

Typical  types  of  information  which  the  System  Status  capability  will 
provide  include: 

1.  Drive  system  status 

a.  Fuel  status — fuel  remaining,  current  fuel  mixture 

b.  Oil  status — pressure,  temperature,  oil  remaining 

c.  Engine  temperature,  coolant  status 

d.  Vehicle  interior  heating/cooling  status — current 
temperature,  operability,  coolant  remaining 

e.  Vehicle  speed — km/hr,  acceleration,  engine  RPMs, 
drive  mode  operability,  current  drive  mode 

f.  Current  navigational  direction 

g.  Current  steering  angle 

h.  Vehicle  maneuverability  status/restrictions 

2.  Traction  system  status 

a.  Current  attitude — roll,  pitch,  yaw 

b.  Current  vibration  level 
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3.  Platform  support/damage  control  monitor 

a.  Terrain  crossing  status/limitations 

b.  Damage  status — location,  extent,  functional 
limitation 

4.  Electrical  and  electronic  system  status 

a.  Engine  control  system  status — charge/discharge  status 

b.  Back-up  electrical  system  status/availability 

c.  Electrical  power  distribution  system  status 

d.  Vehicular  instrumentation  system  status 

e.  Fire  control  system  status 

f.  Stabilization  system  status 

g.  Tactical  Situation  Display  status 

5.  Communications  systems  status 

a.  Operability  status 

b.  Current  utilization — frequencies ,  assignments 

c.  Alternative  available  channels 

d.  Hi/lo  power  indications 

e .  COMSEC  status 

6.  Sensor  systems  status 

a.  NBC  threat  system  status 

b.  Fire  threat  system  status 

c.  Laser  threat  system  status 

d.  Optical  threat  system  status 

e.  Enemy  helicopter  (acoustic)  threat  system  status 

f.  Thermal  sight  system  status 
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7.  Countermeasure  systems  status — operability,  orientation/aim 

a.  NBC  protection  system  status 

b.  Fire  suppression  system  status 

c.  Optical  jammer  status 

d.  Semi-automatic  counterfire  status 

e.  Laser  shutter  status 

f.  Smoke/decoy  system  status 

8.  Weapons  systems  status — for  each  on-board  weapon 

a.  Operability 

b.  Orientation/aim 

c .  Temperature 

d .  Ammo  loaded 

e.  Performance  capability — range,  accuracy,  elevation 
limits ,  kill  probability  or  target  dependencies ,  train 
rate 

9.  Ammunition  status 

a.  Types 

b.  Amounts  available 

c.  Usage  rates 

Some  of  the  status  indicators  listed  above  will  be  routinely  available 
to  at  least  some  of  the  crew  via  standard  displays,  e.g.,  the  vehicle's 
speed  will  be  available  to  the  vehicle  driver  via  the  speedometer;  the  radio 
operator  will  have  firsthand  knowledge  of  frequency  assignments.  But  it  also 
will  be  necessary  for  the  tank  commander  at  times  to  access  a  variety  of 
different  status  informations  on  which  to  make  decisions  and  by  which  to 
forward  information  to  the  unit  commander. 

DERIVED  SOLDIER-MACHINE  INTERFACE  IMPLICATIONS 

Vetronics  must  provide  the  essential  on-board  visual  displays  and  other 
crew  interface  devices  necessary  for  the  vehicle  crew  and  the  crew  commander 


to  perform  effectively.  These  devices  must  provide  the  essential  information 
when  needed,  present  no  more  information  them  needed  or  requested,  and  produce 
the  information  on  a  timely  and  accurate  basis. 

The  great  number  of  potential  status  indications  listed  above  (and  there 
are  undoubtedly  many  more),  and  the  environment  in  which  the  information  will 
be  requested  and  used,  present  some  serious  implications  for  the  design  of  the 
devices.  Continual  display  of  all  status  indicator  dimensions  is  out  of  the 
question  for  two  reasons :  space  limitations  within  the  vehicle  and  sensory 
over-saturation  of  the  crew.  Thus,  it  is  imperative  that  individual  crew 
members  have  the  capability  to  access  specific  pieces  of  system  status  data 
on  command.  Further,  likely  all,  or  nearly  all,  status  information  should  be 
accessible  to  the  vehicle  commander,  likewise  on  command  and  independently. 
Space  limitations  within  the  vehicle  have  implications  for  multi-function 
controls  and  displays,  i.e.,  utilization  of  mode  controls  to  expand  individual 
controls  and  displays  to  multi-function  capability. 

Use  considerations  will  probably  indicate  certain  configurations  of 
status  data.  Analyses  should  be  made  to  determine  what  these  combinations 
ought  to  be.  Configurations  of  status  data  could  greatly  reduce  the  crew's 
burden  of  learning  and  using  independent  request  sequences  for  separate  pieces 
of  data.  Standardization  of  request  and  display  features  is  also  in  order. 

For  example,  countermeasure  systems  status  data  could  standardly  provide 
operability  and  orientation/aid  information  for  each  countermeasure  type. 
Standardized  formatting  of  requests  (inputs)  and  of  information  presentation 
(outputs)  are  appropriate  here. 

The  choppy  nature  of  the  battlefield  terrain  poses  severe  problems  for 
the  design  of  controls  and  displays.  Keyboards,  small  function  keys,  and  touch 
panels  are  poor  candidates  for  accurate  insertion  of  commands  in  a  moving 
vehicle  on  a  volatile  battlefield.  Such  uneven  hand  manipulation  conditions 
usually  indicate  the  need  for  utilization  of  speech  commands.  However,  the 
noise  of  the  battlefield  will  impact  the  efficacy  of  use  of  voice  as  a 
control  medium.  Consideration  should  be  given  to  employment  of  dual  command/ 
request  capabilities--!. e . ,  utilization  of  both  manual  and  voice  inputs. 
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RECOMMENDATIONS 

1.  Standardize  the  System  Status  command/display  features  to  the 
extent  possible. 

2.  Determine  and  implement  status  data  configurations  to  reduce 
crew  burden  in  accessing  status  data. 

3.  Employ  multi-function  controls  and  displays  to  accommodate 
to  within  the  vehicle  space  limitations. 

4.  Provide  dual  command/request  media  to  overcome  the  difficulties 
of  the  battlefield  environment. 

5.  Sections  of  the  Prototype  Handbook  relating  to  the  SMI  of  the 
System  Status  capability  are: 

1.1  Alphanumeric  Control  Methods 

1.2  Graphics  Control  Methods 

1 . 3  HELPS 

2.1  Alphanumeric  Displays 

2.2  Graphics  Displays 

3.2  Unburdening  of  Input 

4.1  Composition  Aids  for  Alphanumeric  Messages 

4.2  Composition  Aids  for  Graphics  Displays 

5 . 1  Query  Method 

5.2  Query  Structure 

6.1  Symbols  and  Symbol  Sets 

6.2  Standard  Terms 

6.3  Abbreviations  and  Codes 

7.1  Error  Feedback 

7.2  Error  Correction  and  Recovery 


Diagnostics/Prognostics 
INFERRED  FUNCTIONAL  DESCRIPTION 

This  capability  will  provide  diagnostic  and  prognostic  information  to 
the  crew  when  vehicle  failure  or  critically  reduced  vehicle  performance 
capacity  is  indicated.  Typical  types  of  information  might  include: 

1.  For  a  low  fuel  status  indication: 

a.  Amount  of  fuel  remaining. 

b.  Achieved  rate  of  consumption  under  known  conditions. 

c.  Average  rate  of  consumption. 

d.  Navigable  distance  remaining  under  different  speed 
conditions. 

e.  Turn-around  point/distance  to  reach  refueling  station 
safely. 

f.  Information  regarding  vehicle  failure  condition 
causing  undue  loss  of  fuel. 

2.  For  a  low  oil  pressure  status  indication: 

a.  Actual  pressure  reading. 

b.  Reason  for  oil  pressure  failure. 

c.  Projected  time/distance  to  "dead"  or  critically 
damaged  status. 

d.  Oil  quantity  remaining. 

e.  Oil  temperature. 

3.  For  an  overheated  engine  indication: 

a.  Actual  temperature  reading. 

b.  Reason  for  engine  overheat. 

c.  Projected  time/distance  to  "dead”  or  critically 
damaged  status. 


d.  Projected  cool-down  time  to  bring  engine  to 
within-tolerance  temperature. 


4.  For  a  malfunction  indication  in  the  vehicle's  heating 
system: 

a.  Nature  of  the  malfunction. 

b.  Highest/lowest  internal  vehicle  (crew  area)  temperature 
expected  after  what  duration  of  time . 

5.  For  a  malfunction  indication  in  the  vehicle's  cooling 
system: 

a.  Nature  of  the  malfunction. 

b.  Highest/lowest  interned  vehicle  (crew  area)  temperature 
expected  after  what  duration  of  time. 

Routine  status  of  any  of  the  above  systems  will  likely  be  indicated  to 
the  crew  through  standard  automotive  displays  such  as  meters,  gauges,  and 
indicator  lights.  Such  displays  have  the  capacity  to  inform  the  crew  of 
normal  operating  status  and  even  to  indicate  trouble  symptoms.  However,  the 
nature  of  the  environment  in  which  the  crew  and  vehicle  function  is  such  that 
under  seme  conditions  inadequate  attention  might  be  paid  to  routine  display 
of  malfunction  indicators— in  the  middle  of  heavy  battle,  for  example.  The 
Diagnostics/Prognostics  function  differs  from  routine  status  readouts  in  the 
following  ways: 

1.  it  calls  out  a  "trouble"  condition  rather  than  routine 
status . 

2.  It  identifies  the  nature  of  the  "trouble,"  thereby  allowing 
the  crew  to  make  a  decision  as  to  how  to  handle  the  problem — 
e.g.,  repair,  return,  ask  for  help. 

3.  It  provides  additional  information  to  assist  the  crew  in 
making  the  above  decision — e.g.,  for  a  lew  fuel  status  indi¬ 
cation,  the  turn-around  point/distance  to  reach  refueling 
station  safely;  for  a  low  oil  pressure  status  indication, 
the  projected  time/distance  to  "dead"  or  critically  damaged 
status . 

DERIVED  SOLDIER-MACHINE  INTERFACE  IMPLICATIONS 

The  Diagnostics/Prognostics  capability  interfaces  directly  to  the  crew 
via  automatic  messages.  Further,  messages  of  diagnostic/prognostic  infor¬ 
mation  should  be  such  that  they  cannot  be  overlooked  by  the  crew  and,  under 
some  conditions,  cannot  be  ignored;  but,  conversely,  under  other  conditions, 


a  manual  override  should  be  possible.  These  display-response  conditions  are 
implicit  to  the  level  and/or  stage  of  battle  or  maneuver.  For  example,  the 
crew  is  going  to  be  much  more  protective  of  the  vehicle  during  practice 
maneuvers  than  during  battle — probably  opting  to  return  to  "garrison"  for 
even  the  slightest  trouble  indication.  On  the  other  hand,  if  the  battle  is 
all  but  won,  the  crew  would  probably  opt  to  continue  even  if  the  vehicle 
would  be  out  of  commission  immediately  after  the  last  target  were  taken. 

These  same  conditions  apply  to  the  vehicle's  internal  heating  and  cooling 
systems,  with  the  crew  tolerating  temperature  extremes  for  whatever  required 
periods  of  time  more  readily  under  battle  conditions  than  under  practice 
maneuver  conditions. 

Ways  in  which  the  crew  could  be  notified  of  vehicle  problems  or  malfunc¬ 
tions — when  there  is  an  implication  that  the  problem  or  malfunction  is  likely 
to  disable  the  crew  or  the  vehicle — include  an  aural  message;  a  textual 
message  via  a  display  screen  identifying  the  system  at  fault  and  the  nature 
and  severity  of  the  trouble;  a  series  of  blinking  lights  which  identifies  the 
system  at  fault;  or  a  larger  set  of  blinking  lights  which  also  identifies  the 
nature  of  the  problem.  Some  combination  of  aural,  blinking  lights,  and 
textual  information  to  the  crew  is  probably  required — aural  notification 
to  gain  the  attention  of  the  crew — although  even  that  poses  some  problems 
under  battle  condition — and  visual  display  to  provide  specific  diagnostic 
and  prognostic  information. 

The  crew  should  be  required  to  acknowledge  the  message  through  a  simple 
mechanism  such  as  a  push-button.  But,  the  crew  should  also  have  the  option 
of  indicating  to  the  Diagnostic/Prognostic  capability  that  no  immediate 
attention  will  be  given  to  the  problem. 

RECOMMENDATIONS 

The  following  recommendations  assume  more  than  simple  provision  of 
diagnostic/prognostic  information  via  the  Vetronics  Diagnostics/Prognostics 
capability. 

1.  The  crew  should  be  notified  immediately  when  conditions 
indicate  a  potential  vehicle  failure  or  a  critically 
reduced  performance  capacity.  This  message  should  be 
in  three  parts: 


a.  An  aural  indication,  e.g.,  bell,  siren,  which 
precludes  the  crew's  overlooking  the  message. 

b.  Notification  of  the  "threatened"  vehicle  system. 

c.  Substantive  information  about  the  nature  of  the 
trouble  from  which  the  crew  is  able  to  perform 
decision-making  as  to  corrective  options. 

Notification  should  remain  on  the  display  device (s)  until 
acknowledged  by  the  crew. 

Sections  of  the  Prototype  Handbook  relating  to  display  issues 
in  the  Diagnostics/Prognostics  capabilities  of  Vetronics  are: 

2.1  Alphanumeric  Displays 

2.2  Graphics  Displays 

2.3  Selective  Highlighting 

4.1  Composition  Aids  for  Alphanumeric  Messages 

6.1  Symbols  and  Symbol  Sets 

6.2  Standard  Terms 

6.3  Abbreviations  and  Codes 

With  respect  to  the  crew's  ability  to  override  the  diagnostic/ 
prognostic  notification,  the  crew  needs  control  methods  capa¬ 
bilities.  Relevant  guidelines  for  control  methods  and  guide¬ 
lines  appropriate  to  a  manual  override  are  presented  in  the 
following  sections  of  the  Prototype  Handbook: 

1.1  Alphanumeric  Control  Methods 

1.2  Graphics  Control  Methods 

3.1  Information  on  Legal  Entries 

3.3  Interrupts  and  Work  Recovery 

4.1  Composition  Aids  for  Alphanumeric  Messages 

6.1  Symbols  and  Symbol  Sets 

6.2  Standard  Terms 


6.3  Abbreviations  and  Codes 


Battlefield  Identification  Friend  or  Foe 


INFERRED  FUNCTIONAL  DESCRIPTION 

The  Battlefield  Identification  Friend  or  Foe  (BIFF)  system  receives  and 
interprets  electronic  signals  defining  another  combat  vehicle's  tactical 
identification  as  a  friend  or  foe.  A  future  technology  is  intended  to  add 
the  capability  of  identifying  neutrals.  The  BIFF  system  consists  of  the 
following  capabilities: 

1.  Automatic  interrogation  and  interpretation  of  electronic 
tactical  identification  signals  received  from  other  combat 
vehicles. 

2.  Computer  output  of  identification  status  (i.e.,  symbols 
indicating  friend,  foe,  or  neutral  combat  vehicle). 

3.  Crew  interrogation  capability,  for  verifying  computer- 
determined  identification  status.  The  crew  interrogation 
capability  consists  of: 

a.  System  capability  that  allows  crew  members  to  elec¬ 
tronically  "question"  other  combat  vehicles  as  to 
whether  they  are  friend  or  foe. 

b.  System  capability  that  allows  crew  members  to  verbally 
request  another  combat  vehicle  to  further  describe 
itself,  thereby  providing  means  for  more  in-depth 
questioning  and  verification. 

c.  A  developing  technology  suitable  for  supporting  the 
BIFF  application  concerns  the  detection  of  vehicle 
electromagnetic  emanations.  The  signature  from  these 
radiations  can  be  detected  and  electronically  compared 
to  stored  signatures  of  hostile  vehicles.  BIFF  infor¬ 
mation  can  be  gained  as  a  result. 

The  BIFF  system  will  have  two  operational  modes — automatic  and  inter¬ 
mittent  manual.  The  electronic  interpretation  and  display  of  vehicle 
identification  status  will  be  automatic.  However,  the  crew's  verbal  interro¬ 
gation  capability  will  be  primarily  manual  with  periodic  automatic  functions. 


DERIVED  SOLDIER-MACHINE  INTERFACE  IMPLICATIONS 

The  BIFF  system  provides  the  crew  with  information  classifying  combat 
vehicles  as  either  friendly  or  unfriendly.  On  the  battlefield,  an  unfriendly 
vehicle  is  likely  to  be  a  hostile  force  and  a  threat  to  the  combat  vehicle. 


Integrating  the  BIFF  capability  into  Vetronics  will  allow  for  the  presentation 
of  this  status  information  through  the  Tactical  Situation  Display.  Of  critical 
significance  is  the  display  of  a  BIFF  system-defined  foe  as  a  warning.  This 
warning  should  be  provided  to  the  crew  immediately  after  it  has  been  determined. 

It  is  assumed  that  the  BIFF  system  is  able  to  determine  that  the  vehicle 
is  being  interrogated  by  a  signal  that  is  not  within  the  specification  for 
friendly  forces.  The  possibility  exists  that  the  combat  vehicle  can  be 
interrogated  by  a  hostile  vehicle  and  the  crew  should  immediately  be  made 
aware  of  this.  Armed  with  this  knowledge,  the  crew  can  follow  procedures 
established  for  this  situation. 

Additionally,  the  crew  may  wish  to  know  when  the  BIFF  system  is  performing 
its  automatic  function  of  responding  to  friendly  interrogation  at  an  unusually 
high  occurrence.  An  unusually  high  number  or  rate  of  acknowledgements  may 
indicate  that  the  receiving  unit  in  the  transmitting  vehicle  is  malfunctioning 
or  not  receiving  a  signal.  Radio  or  other  inter-vehicle  communication  may 
be  advised. 

The  Tactical  Situation  Display,  as  it  supports  the  BIFF  capability, 
provides  the  crew  with  real-time  notification  of  probable  and  possible  threat 
situations.  Crew  decisions  will  then  be  limited  to  selecting  from  a  limited 
number  of  procedural  alternatives. 

RECOMMENDATIONS 

1.  Sections  of  the  Prototype  Handbook  relating  to  guidelines 

useful  to  the  incorporation  of  BIFF  capabilities  to  meet 

crew  requirements  are : 

1.1  Alphanumeric  Control  Methods 

1.2  Graphics  Control  Methods 

2.1  Alphanumeric  Displays 

2.2  Graphics  Displays 

2.3  Selective  Highlighting 

3.2  Unburdening  of  Input 

6.1  Symbols  and  Symbol  Sets 

6.3  Abbreviations  and  Codes 


The  following  guidelines  were  derived  from  the  Prototype  Handbook  and 
tailored  to  the  BIFF  application. 

2.  Display  those  BIFF-de fined  foes  whose  position  is  known  as 
flashing  graphics  on  the  Tactical  Situation  Display.  Use 
the  color  red  if  available,  and  augment  the  warning  aurally. 

3.  Indicate  aurally  and  alphanumerically  the  receipt  of 
unidentifiable  interrogation  signals. 

4.  Advise  the  crew  of  continuous  and  repeated  BIFF  acknowl¬ 
edgements  of  friendly  interrogations. 

5.  Provide  a  convenient  means  for  the  crew  to  manually  initiate 
a  BIFF  interrogation.  Provide  this  capability  from  two  crew 
stations. 

6.  Where  space  permits,  provide  alphanumeric  status  displays  of 
uninterrogated  vehicles  appearing  on  the  Tactical  Situation 
Display.  Use  "UNKNOWN"  status  label  followed  by  an  aural 
warning  if  interrogation  is  not  completed  within  a  specified 
time  period. 


Tactical  Situation  Displav 


INFERRED  FUNCTIONAL  DESCRIPTION 

Today's  combat  vehicle  employs  sophisticated  electronics  to  support  and 
enhance  both  offensive  and  defensive  roles.  The  inclusion  of  the  VIDS-DMS, 
with  its  peripheral  detectors  and  sensors,  provides  the  combat  vehicle  crew 
with  early  warning  of  hostile  presences.  The  early  warning  also  furnishes 
the  crew  with  sufficient  information  to  determine  if  they  should  initiate 
defensive  or  offensive  maneuvers.  Electronics  supporting  fire  control  systems 
also  provide  the  crew  with  the  increased  speed  and  accuracy  required  for 
increased  probability  of  one  shot/first  shot  kills.  PLRS,  when  available, 
will  provide  the  crew  with  on  demand,  real-time  update  of  the  combat  vehicle's 
present  position.  Additionally,  information  from  instrumentation,  internal 
sensors,  and  system  monitoring  devices  provides  the  crew  with  real-time  status 
indication  of  the  combat  vehicle's  internal  devices. 

Internal  data  storage  can  hold  detailed  information  identifying  terrain 
features,  positions  of  hostile  sensors  and  weapons,  and  latest  information  on 
the  conditions  of  bridges,  roads,  and  traversable  surfaces.  Internal  storage 
also  holds  details  of  the  battle  plan,  objectives,  targets,  contingency  plans, 
alternative  routes,  and  rules  of  engagement.  This  information  is  available 
to  the  crew  on  an  on  demand  basis  anytime  during  the  conduct  of  a  mission. 

At  present,  the  crew  must  integrate  this  substantial  amount  of  data,  make 
decisions,  and  perform  some  kind  of  manual  response.  The  substantial  amount 
of  data  is  not,  of  itself,  detrimental  to  crew  performance;  data  serves  a 
genuine  crew  function  of  decision  making.  Problems  arise  when  the  crew  must 
serve  as  a  data  integrator,  make  critical  decisions  quickly,  and  perform 
manual  functions.  All  too  frequently,  the  addition  of  a  new  capability  to  a 
combat  vehicle  results  in  an  additional  data  integration-decision  making-task 
performance  cycle  for  the  crew.  Increasing  the  number  of  automatic  assists  to 
the  crew  aids  task  performance  simply  by  eliminating  those  tasks  replaced  by 
automatic  assists.  However,  automatic  assists  are  impractical  for  many  combat 
vehicle  tasks,  and  the  crew  still  has  the  function  of  data  integration. 

Vetronics  will  offer  assistance  in  relieving  this  type  of  workload  by 
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integrating  the  data  produced  by  the  combat  vehicle's  internal  systems  and 
providing  the  data  in  a  usable  format  through  the  Tactical  Situation  Display. 
The  Tactical  Situation  Display  will  perform  the  function  of  displaying  data 
required  by  the  crew  to  perform  tasks.  The  Tactical  Situation  Display  is  a 
flat  display  capable  of  both  digital  and  graphic  representation.  In  a  sense, 
the  Tactical  Situation  Display  is  the  key  output  device  of  Vetronics  and  a 
principal  component  of  the  soldier-machine  interface. 

DERIVED  SOLDIER-MACHINE  INTERFACE  IMPLICATIONS 

Whereas  the  VIDS-DMS  functions  in  an  essentially  transparent  manner  to 
the  crew,  Vetronics  should  come  close  to  being  its  opposite.  Vetronics, 
through  the  SMI,  can  furnish  real-time  integrated  information  to  the  crew  on 
a  continuous,  as  required,  or  by  exception  basis.  Importantly,  the  information 
provided  to  the  crew  should  be  limited  to  particulars  required  to  perform  the 
tasks,  and  presented  in  a  format  most  useful  for  the  decision  making  or  problem 
solving  required  by  the  task.  For  example,  terrain  data,  topographical 
features  (both  man-made  and  natural),  and  hostile  forces  positions,  are  best 
represented  graphically.  This  information  and  format  is  best  suited  for 
supporting  combat  roles,  and  the  task  of  Maneuver/Navigate.  Data  regarding 
range,  elevations,  position  identification,  compass  bearing,  etc.,  are  best 
presented  digitally.  Information  of  this  nature  and  format  is  also  applicable 
to  the  Maneuver/Navigate  task.  Alphanumeric  data  formats  best  communicate 
Prognostics/Diagnostics  information  to  the  crew.  Status  information  such  as 
vehicle  speed,  fluid (s),  temperature,  pressure,  or  level  have  historically 
been  presented  as  analogs;  existing  vehicle  instrumentation  may  continue  this 
trend.  Display  of  routine  status  data  is  probably  not  a  function  of  the 
Tactical  Situation  Display.  Should  the  status  monitoring  sensors  determine 
that  a  failure  is  imminent,  then  status  information  serves  the  purpose  of  a 
warning.  This  information  may  be  displayed  on  the  Tactical  Situation  Display 
in  alphanumeric  format. 

Data  display  and/or  data  storage  limitations  will  restrict  the  amount  of 
on  demand  data  available  to  the  crew.  Decisions  of  what  data  to  display 
should  be  based  on  priority  analyes.  Many  on  demand  data  items  can  be  as¬ 
signed  to  the  same  area  of  the  Tactical  Situation  Display  to  alleviate  the 
data  display  overload  problem.  System-generated  exception  messages  can  be 


displayed  alphanumerical ly  in  a  specially  reserved  space  to  inform  the  crew  of 
impending  failure. 

The  Vetronics  SMI  can  provide  required  information  in  optimum  format 
(digitally,  graphically,  or  analog)  and  do  so  in  a  continuous,  on  demand, 
or  by  exception  manner.  Data  access  by  the  crew,  especially  under  high  stress 
and  physically  buffetting  conditions,  will  require  special  attention  in  the 
Vetronics  SMI  design.  Fixed  function  keys,  physically  oversized  and  well 
spaced  for  "canned"  queries,  and  function  selector  knobs  limited  to  no  more 
than  two  functions  will  assist  the  crew  in  making  rapid  transactions.  The 
installation  of  a  standard  data  entry  keyboard  for  use  when  combat  missions 
are  underway  should  not  be  considered.  The  characters  and  symbols  presented 
on  the  Tactical  Situation  Display  should  be  appropriately  sized  to  provide 
legibility  under  conditions  of  vehicle  vibration,  roll,  and  pitch.  Vetronics' 
SMI  implications,  therefore,  call  for  design  of  a  Tactical  Situation  Display 
that  exhibits  such  human  engineering  concepts  as  viewability,  legibility,  and 
operability,  as  well  as  incorporation  of  data  management  concepts  such  as 
rapid  access,  data  formats  appropriate  to  data  type,  and  data  integration. 


RECOMMENDATIONS 

Recommendations  1  through  13  below  were  derived  from  the  Prototype 
Handbook  and  tailored  to  support  the  interface  design  of  the  Tactical  Situation 
Display. 

1.  Provide  the  crew  with  a  display  of  a  geographical  area  large 
enough  to  contain  any  known  hostile  weapon  position  whose 
range  threatens  the  crew's  present  position.  "Weapons"  is 
not  intended  to  include  items  such  as  a  foot  soldier  with  a 
shoulder  mounted  rocket  launcher,  or  a  helicopter  presently 
parked  50  miles  away  from  the  crew's  position. 

2.  Provide  the  crew  with  a  display  of  a  geographical  area  with 

a  crew-selectable  expanded  scale.  The  detail  of  the  expanded 
scale  shall  be  sufficient  to  reveal  major  topographical  fea¬ 
tures  and  hostile  forces  threat  data. 

3.  In  the  event  hostile  threats  are  detected  at  a  range  beyond 
the  geographical  area  accounted  for  by  the  terrain  display's 
normal  scale,  provide  the  capability  for  automatic  switch 
to  expanded  scale,  if  the  increased  range  will  reveal  the 
threat. 


4.  Reserve  a  section  of  the  Tactical  Situation  Display  for  the 
display  of  exception  messages  to  the  crew.  Provide  these 
messages  alphanumerically . 

5.  If  real-time  information  updates  include  new  threat  data 
(e.g.,  VIDS-DMS  data),  provide  that  information  with  an 
alerting  mechanism,  such  as  blinking  lights,  inverse  video, 
color  code,  or  audio  alert.  Require  a  crew  acknowledge 
through  a  push-push  switch  to  extinguish  the  alerting 
mechanism. 

6.  If  system  status  information  is  to  be  presented  on  the  Tactical 
Situation  Display,  require  a  crew  member  to  initiate  a  query 
for  it.  Exception:  If  the  system  senses  an  impending  failure, 
a  notification  should  be  provided  automatically. 

7.  Specify  Prognostic/Diagnostic  messages  to  include  alphanumeric 
identifications  of  the  malfunctioning  component. 

8.  Allow  sufficient  range  in  the  display  of  terrain  data  so  that 
both  the  objective's  and  crew's  current  positions  are  simultane¬ 
ously  displayed. 

9.  Provide  sufficient  terrain  relief  and  artifact  features  in 
the  topographic  display  to  allow  the  crew  to  make  maneuver/ 
navigate  decisions. 

10.  Display  updated  status  information  (threat,  open  or  closed 
bridges,  open  or  closed  roads,  etc.)  through  the  terrain  dis¬ 
play  as  blinking  graphics  characters.  Require  the  crew  to 
acknowledge  their  presence  through  push-push  switches. 

11.  Provide  terrain/terrain  relief  data  on  the  topographic  display 
with  enhancements  to  include  routes  negotiable  by  combat 
vehicles;  bridges;  fordable,  non-fordable  streams;  and  "slow 
footing"  surfaces. 

12.  Consider  the  Tactical  Situation  Display's  characteristics  of 
resolution,  size,  brightness,  contrast,  and  color  capability 
as  a  contributing  factor  in  specifying  the  size  of  graphics 
and  digital  characters. 

13.  Provide  the  on  demand  capability  to  display  the  stores  inven¬ 
tory  through  the  Tactical  Situation  Display  or  a  display  in 
close  proximity. 

14.  Sections  of  the  Prototype  Handbook  relating  to  display  issues 
which  will  be  helpful  in  the  design  of  the  Vetronics  Tactical 
Situation  Display  include: 

1.1  Alphanumeric  Control  Methods 

1.2  Graphics  Control  Methods 
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2.1 


Alphanumeric  Displays 
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2.2  Graphics  Displays 

2.3  Selective  Highlighting 

3.2  Unburdening  of  Input 

5.1  Query  Methods 

6.1  Symbols  and  Symbol  Sets 

6.3  Abbreviations  and  Codes 

7.1  Error  Detection/Feedback 

7.2  Error  Correction  and  Recovery 

EXAMPLE  OF  HANDBOOK  USAGE 

As  an  example,  the  Prototype  Handbook  in  Section  2,  "Display  Techniques," 
presents  guidelines  on  techniques  to  present  information  to  the  crew.  Example 
applications  are  presented  that  are  relevant  to  the  requirements  of  the 
Tactical  Situation  Display.  Three  such  examples  are  reproduced  from  the 
Prototype  Handbook's  Section  2.2.2,  "Applications  for  Graphics  Displays , "  items 
c,  d,  and  e.  Note  that  the  applications  are  weighted  toward  creating 
graphics  displays  rather  than  their  use  as  an  output  device.  This  does  not 
diminish  their  merit  for  guidance  in  developing  a  Tactical  Situation  Display, 
as  the  information  displayed  is  substantially  the  same.  The  three  applications 
are  as  follows: 

"c.  Display  of  topographic  features  in  a  representational  framework. 

EXAMPLE:  In  a  system  which  provides  data  processing  support 
to  a  tactical  command  and  control,  a  graphics  capability  is 
provided.  Maps,  which  are  displayed  on  a  plasma  screen,  can 
be  enhanced  by  entry/deletion/movement  of  special  symbols  and 
creation  of  additional  symbols — all  through  use  of  a  series  of 
fixed  function  keys.  The  generated  symbols  (whether  standard 
doctrinal  symbols  or  newly  created  symbols)  can  be  superimposed 
on  a  displayed  map  to  demonstrate,  for  example,  current,  future, 
or  historical  status  of  a  given  geopolitical  area.  Or,  succes¬ 
sive  overlays  can  be  prepared  to  show  a  variety  of  topographic 
features,  e.g.,  terrain  features,  cultural  features,  rainfall. 

nd.  Creation  of  "free-form"  drawings  and  sketches. 

EXAMPLE:  An  artillery  system  projects  battle  strategies  on 
the  basis  of,  for  example,  terrain  and  cultural  characteristics 
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fire  power,  personnel,  and  interim  battle  outcome  parameters. 

The  tank  commander,  working  on  a  map  grid  of  the  battle  area, 
creates  various  map  overlays  to  aid  in  the  planning  of  battle 
strategies.  Strategies  can  reflect,  for  example,  destroyed/ 
not  destroyed  terrain  and  cultural  features;  personnel  levels 
available  as  a  result  of  battle;  gun  availability  and  ammo 
levels;  terrain  conditions  for  tank  movement.  This  system 
does  not  have  the  capability  to  deal  with  real-time  events  on 
an  automatic  basis.  However,  the  capacity  to  deal  with  time- 
bound  events  (e.g.,  rate  of  advance,  time  to  complete  a  maneu¬ 
ver)  permits  the  tank  commander  to  project  time  into  the 
battle  strategy. 

"e.  Display  of  imagery. 

EXAMPLE;  Certain  types  of  "field  information"  are  required  to 
be  maintained  on  a  continuing  basis  at  headquarters.  These 
data  are  measured  and  transmitted  automatically  as  telemetered 
data.  At  the  receiving  station  at  headquarters,  the  pulses 
are  converted  to  automatic  graphics  output,  sometimes  in  the 
form  of  line  drawings,  sometimes  in  the  form  of  bar  charts, 
sometimes  in  the  form  of  color  graphics." 

Table  1,  which  is  reproduced  from  Table  2-1  of  the  Prototype  Handbook, 
illustrates  applications  and  display  techniques.  The  application  of  the 
Tactical  Situation  Display  most  closely  resembles  a  "Pictorial/Symbolic 
Presentation."  The  display  technique  most  suitable  and  recommended  by  Table  1 
for  this  application  is  the  graphic  type. 

Table  1 

Display  Techniques  by  Application 

«»: 

1  .  APPROPRIATE 

2  -  ACCEPTABLE 

3  -  INAPPROPRIATE 
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To  further  continue  the  example,  methods  for  implementing  graphics  displays 
are  also  discussed  in  the  Prototype  Handbook .  A  summary  of  this  discussion 
is  presented  in  Table  2  which  is  reproduced  from  Table  2.2-1  of  the  Handbook. 
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Method  of  Graphics  Display  by  Application 


The  most  closely  matching  method  to  the  Vetronics  Tactical  Situation 
Display  Maneuver/Navigate  application  is  the  map,  map  overlay  and  chart. 

Two  examples  of  the  map,  map  overlay  and  chart  method  are  reproduced  intact 
from  the  Prototype  Handbook,  Section  2.2.4,  Methods  for  Graphics  Displays, 
item  e,  as  follows: 


Map,  map  overlay,  and  chart.  Maps  and  charts  are  very  ver¬ 
satile  forms  of  graphics  displays.  Maps  usually  depict  the 
topographic — the  natural  and/or  manmade — features  of  a  geo¬ 
graphic  area.  The  term  chart  is  usually  used  to  refer  to 
navigational  maps  showing  coastlines,  water  depths,  celestial, 
or  other  information  of  use  to  navigators. 


.XI 


Sample  map. 


Map  overlays  permit  conversion  of  a  basic  map  to  maps  which 
feature  particular  aspects  of  the  geographic  area,  e.g.,  elevation, 
rainfall,  equipment  emplacement.  The  following  figure  uses  an 
overlay  with  symbolic  notations  to  indicate  both  terrain  features 
and  equipment  placement. 


Sample  map  overlay. " 


SUGGESTED  FUNCTIONAL  DESCRIPTION 


Vetronics'  automated  capabilities  provide  an  opportunity  for  designing 
and  developing  a  comprehensive  on-board  training  module  with  simulated  combat 
conditions.  Following  the  crew's  completion  of  a  classroom  vehicle  training 
program  and  demonstration  that  fundamental  combat  vehicle  operational  skills 
have  been  acquired,  it  is  advisable  that  these  skills  be  applied  under 
simulated  combat  conditions.  Application  of  such  operational  skills,  within 
a  vehicle  that  is  programmed  with  simulated  combat  control  readouts,  provides 
opportunities  for  the  crew  to  maximize  their  skill  proficiency  level  under  a 
variety  of  conditions. 

The  training  program  may  be  designed  as  a  separate  computer  training 
module,  that  could  replace  the  vehicle's  standard  operational  modules.  This 
training  module  will  be  functionally  similar  to  the  standard  operational 
modules,  with  equivalent  types  of  data  read  into  and  displayed  by  the  system. 

Since  combat  conditions  and  consequences  (e.g.,  soldier  death)  may  dictate 
that  crew  members  take  over  operational  responsibilities  not  usually  assigned 
to  them,  such  as  driving  the  combat  vehicle  or  shooting  the  main  gun,  it  is 
advisable  that  all  crew  members  be  given  on-board  training  experience  with 
all  vehicle  functions  and  operations.  Thus,  regardless  of  a  soldier's  intended 
role  on  board  the  combat  vehicle ,  he  should  strive  to  be  proficient  with  all 
vehicle  operations.  It  is  therefore  recommended  that  all  crew  members  undergo 
the  identical  on-board  training  program. 

The  construction  of  the  training  programs  may  be  along  the  following 
five  dimensions: 

1.  Type  of  displayed  simulated  vehicle  sensor  data. 

2.  Measurement  of  crew  performance,  in  response  to  various  combat 
conditions . 

3.  Crew  performance  analyses,  with  accompanying  feedback. 


4.  Characteristics  and  intensity  of  combat  scenarios. 

5.  Graduated  experience  levels. 


Each  of  these  five  dimensions  is  described  below. 

Simulated  Vehicle  Sensor  Data 

A  comprehensive  simulated  combat  training  package  requires  that  a  variety 
of  vehicle  sensor  data  be  displayed  to  reflect  differentially  orchestrated  combat 
scenarios.  The  vehicle  sensor  data  will  include  peripheral  sensor  data,  such 
as  provided  by  the  optical  threat  detector;  and  vehicle  status  data,  such  as 
speedometer  readings.  The  various  types  of  simulation  combat  modules  will 
have  different  programmed  sensor  data,  to  accommodate  varying  complexity  and 
intensity  combat  situations  and  soldier  experience  levels. 

Crew  Performance  Measurement 

In  order  to  monitor  the  crew's  responses  to  the  various  combat  scenarios, 
it  is  necessary  to  record  the  crew's  performances  as  they  interact/respond 
to  the  combat  conditions  represented  by  the  simulated  sensor  readings.  The 
following  measures  are  examples  of  the  types  of  data  that  may  be  collected 
to  provide  information  on  crew  progress  and  proficiency  level ,  during  the 
various  combat  conditions : 

1.  Reaction  time  to  specific  sensor  signals. 

2.  Specific  type  of  response  to  sensor  data. 

3.  Response  sequence  (e.g.,  chain  of  specific  actions  such  as 
required  to  start  the  vehicle  engines) . 

4.  Response  amplitude  (e.g.,  voice  magnitude). 

5.  Rate  of  responding. 

Performance  Analyses 

The  effectiveness  of  training  experiences  is  largely  dependent  on  the 
analysis  and  subsequent  feedback  of  crew  performance.  Thus,  it  is  advisable 
to  use  the  Vetronics  capability  for  analyzing  and  providing  immediate  feed¬ 
back  to  the  crew  on  the  accuracy,  consistency,  and  duration  of  their  responses 


to  predetermined,  detailed  conditions.  It  can  be  expected  that  the  quality 
and  reliability  of  skills  will  be  dependent,  to  sane  degree,  upon  how  infor¬ 
mation  (feedback)  about  past  and  present  performance  is  transformed  into 
soldier  expectations  about  future  behavior  (motivation).  Subsequent  soldier 
performance  is  built  upon  these  expectations  and  goals,  and  continuously 
altered  and  refined. 

The  evaluation  of  crew  performance  consists  of  comparing  their  responses 
with  environmental  or  system  quantity  and  quality  standards.  These  performance 
outcome  or  effect  criteria  include,  but  are  not  restricted  to: 

1.  Skill  mastery. 

2.  Knowledge  proficiency. 

3.  Problem  solving  success. 

4.  Skill  generalizibility  (to  other  tasks,  situations,  content 
areas,  physical  and  social  environments). 

A  soldier's  conceptualization  of  the  quality  and  accuracy  of  his  perfor¬ 
mance  is  affected  by  the  characteristics  of  the  evaluative  performance  feed¬ 
back  (reinforcement) .  Critical  feedback  elements  include ,  but  are  not  restricted 
to: 

1.  Speed.  The  more  promptly  feedback  is  provided  after  the 
soldier  responds,  the  greater  the  opportunity  for  increased 
precise  learning. 

2.  Specificity.  The  more  narrowly  feedback  focuses  on  the  specific 
soldier  response,  the  more  effective  it  will  be. 

3.  Accuracy.  Any  imprecision  or  error  in  feedback  is  likely  to 
encourage  performance  that  is  contrary  to  intentions. 

4.  Content .  The  information  content  and  media  should  be  appro¬ 
priate  to  the  desired  response.  For  maintaining  alertness 
and  guiding  simple  responses,  bells,  lights,  and  other  signals 
may  be  appropriate.  Complex  behavior,  such  as  decision  making 
and  problem  solving,  may  require  more  elaborate  information 
feedback . 

5.  Amplitude.  To  be  effective  in  modifying  solider  responses, 
feedback  must  be  easily  perceived  to  gain  the  soldier's  atten¬ 
tion.  However,  feedback  that  is  excessive  or  has  emotional 
implications  may  actually  be  disruptive  to  desired  performance. 


In  addition  to  using  the  Vetromcs  capabilities  for  the  diagnosis  and 
correction  of  crew  performance,  under  varying  simulated  combat  conditions, 
the  system  may  be  programmed  to  provide  response  prompts  to  the  crew.  If 
a  solider  does  not  respond  to  sensor  messages  or  data  within  a  predetermined 
time,  as  measured  by  a  timing  circuit,  appropriate  system  instructions  may  be 
provided  to  the  soldier. 


Simulated  Combat  Scenarios 

A  comprehensive  training  program  requires  that  the  crew  practice  the 
application  of  their  new  skills  on  board  the  vehicle,  under  a  variety  of 
computer  simulated  combat  conditions.  The  simulated  vehicle  sensor  data 
(previously  described) ,  would  be  differentially  combined  within  a  number  of 
combat  modules  to  represent  a  hierarchy  of  combat  scenarios.  These  combat 
modules  would  be  designed  from  the  following  two  dimensional  perspective: 

1.  Combat  intensity — e.g.,  number  and  degree  of  enemy  signals 
and  attacks. 

2.  Combat  functions — e.g.,  number  and  type  of  crew  response 
actions  required. 

Soldier  Experience  Level 


In  order  to  accommodate  the  varying  soldier  experience  and  skill  levels, 
the  on-board  simulated  combat  modules  should  be  tailored  to  the  novice,  as 
well  as  the  highly  skilled  crew  members.  The  training  modules  for  the  novice 
crew  members  would  require  (1)  more  system  prompts  and  (2)  combat  scenarios 
with  less  combat  intensity  and  functional  responsibilities,  thus  allowing 
the  novice  crew  member  an  opportunity  to:  (1)  practice  recently  acquired 
classroom  skills  under  less  stressful  conditions;  (2)  receive  precise  perfor¬ 
mance  feedback;  (3)  respond  to  system  prompts  during  periods  of  response 
uncertainty;  (4)  modify  and  refine  response  skills  as  combat  scenarios  inten¬ 
sify;  and  (5)  gain  confidence  in  response  capabilities.  As  the  crew  develops 
experience  and  skills,  the  simulated  combat  scenarios  will  gradually  increase 
in  intensity  and  complexity. 
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DERIVED  SOLDIER-MACHINE  INTERFACE  IMPLICATIONS 


V.' 

^  4 


R 


$ 

& 


p 


£•1 

$ 


w. 


I 


*: 


.V 


ia 


fi* 


The  on-board  training  modules  require  a  variety  of  system  input/output 
components  that  interface  with  the  crew.  To  enhance  the  crew's  application 
of  their  recently  acquired  skills  on  board  the  combat  vehicle,  the  standard 
combat  vehicle's  operational  and  training  modules  should  be  designed  to  opti¬ 
mize  crew  members'  satisfaction  and  performance  by  facilitating  the  ease  of: 

1.  Obtaining  desired  information. 

2.  Locating/interpreting  displayed  information. 

3.  Entering  commands  and  instructions  for  both  the  standard 
operational  and  training  modules. 

Meeting  these  design  objectives  will  impact  the  precision  of  the  crew's  activi¬ 
ties  by  reducing: 

1.  Memory  loading.  Recall  of:  characteristics  of  enemy  weapons 
systems;  own  vehicle  characteristics;  own  vehicle  vulnerability; 
effect  of  vehicle  weapon  systems  on  enemy  equipment;  soil  char¬ 
acteristics. 

2.  Perceptual  competition.  Requirement  for  attending  to  displays 
rather  than  other  aspects  of  the  environment  or  vehicle  oper¬ 
ations;  requirement  for  understanding  and  acting  upon  displays 
dealing  with  a  variety  of  relevant  topics. 

3.  Motor  activity  requirements.  Selecting  among  different  display 
contents;  selecting  among  different  targets. 

4.  Cognition  requirements.  Integrating  aspects  of  threat  for 
threat  analysis;  comparing  threat  with  time  to  counter  threat; 
assessing  the  role  of  countermeasures  in  threat  reduction. 

The  development  of  the  on-board  training  modules  is  directed  by  the 
following  factors; 

1.  Issues  related  to  system  input: 

a.  Personnel  characteristics. 

b.  Characteristics  of  combat  scenarios. 

c.  Type  and  measurement  of  specific  crew  responses. 
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a.  Peripheral  and  vehicle  sensor  data. 

b.  Crew  prompts  and  instructions. 

c.  Crew  performance  feedback. 


Personnel  Characteristics 


The  design  of  the  training  modules  should  incorporate  the  expected  know' 
ledge,  skill,  and  physical  characteristics  of  the  standard  crew  members. 

Table  3  delineates  critical  personnel  characteristics  and  accompanying  impli 
cations  for  the  soldier-machine  interface. 


Characteristics  of  Combat  Scenarios 

The  design  of  a  hierarchical  set  of  combat  scenarios,  respectively 
reflecting  differential  degrees  of  intensity  and  functional  complexity, 
requires  orchestrating  a  vast  quantity  of  different  peripheral  and  vehicle 
sensor  data.  Tables  A-l  through  A-9  in  the  Appendix  list  the  types  of  infor¬ 
mation  that  should  be  incorporated  to  represent  a  realistic  combat  scenario. 
The  novice  crew  member  could  practice  applying  skills  with  simple  on¬ 
board  training  modules  that  illustrate  low  combat  intensity  levels;  require 
focusing  attention  on  one  instrument  at  a  time;  and  necessitate  one  response 
at  a  time.  As  the  crew  member  gains  additional  hours  of  experience  on 
board  the  vehicle  and  further  assimilates  vehicle  operational  knowledge 
and  skills,  more  intense  and  complex  combat  training  modules  may  be  used. 


Crew  Responses 


Since  the  guidance  of  system  operations  will  be  crew-mediated,  numerous 
human  factors  principles  and  guidelines  must  be  considered  during  the  selec¬ 
tion  of  appropriate  command  media  and  control  methods.  For  example,  many 
of  the  command  situations  which  will  be  encountered  during  combat  vehicle 
unit  operations  will  require  that  the  crew  maintain  relatively  undivided 
attention  on  the  display  of  external  sensors.  Some  form  of  voice  input  or 
simple  keypad  would  appear  to  be  the  most  appropriate  form  of  input  device. 
However,  error  rates  for  voice  input  and  the  sound  spectrum  of  the  internal 
vehicle  environment  may  have  significant  impacts  on  the  viability  of  the 


Table  3 


Critical  Personnel  Characteristics  and  Accompanying 
Implications  for  the  Soldier-Machine  Interface 


PERSONNEL 

CHARACTERISTIC 

IMPLICATIONS  FOR 

SOLDIER-MACHINE 

INTERFACE 

GENERAL  EDUCATIONAL 
LEVEL 

•  Type  of  Interaction  used  in  the  system. 

•  Level  of  complexity  of  syntax. 

e  Characteristics  of  Imbedded  training  systems  and  features, 
e  Training  implications. 

INTELLIGENCE  AND 
APTITUDES 

e  Type  of  Interaction  used  In  the  system, 
a  Level  and  complexity  of  syntax  and  grammar. 

e  Amount  of  memorization  required  for  soldier-computer 
Interaction. 

e  Control  device  selection. 

e  Characteristics  of  Imbedded  training  systems  and  features, 
e  Training  implications. 

RANGE  OF  EXPERIENCE 

IN  MILITARY  AND 
CIVILIAN  LIFE 

e  Requirements  for  tailorable  soldier-computer  Interaction. 

e  Selection  among  alternative  design  features  to  accomodate 
past  soldier  experience. 

PHYSICAL 

CHARACTERISTICS 

/  Strength 

/  Dexterity 

/  Physical  size 
and  Anthropometry 

e  Control  placement  and  design, 
e  Workspace  configuration. 

e  Control  placement  and  design, 
e  Workspace  layout. 

e  Relationship  of  Vetronics  controls  and  consoles  to  other 
equipment  In  the  vehicle. 

e  Control  placement  and  design, 
e  Workspace  layout. 

e  Relationship  of  Vetronics  controls  and  consoles  to  other 
equipment  in  tne  vehicle. 
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Table  3 
(Continued) 


PERSONNEL 

CHARACTERISTICS 

IMPLICATIONS  FOR 

SOLDIER-MACHINE 

INTERFACE 

SENSORY 

CHARACTERISTICS 
/  Hearing 

•  Utility  of  voice  output/synthesized  speech  in  Vetromcs 
operation. 

e  Utility  of  audible  signals. 

J  Vision  . . .  acuity 

e  Size  of  displays, 
e  Characteristics  of  displayed  symbols 

/  Vision  . . .  night 

e  Overall  brightness  of  displays, 
e  Utility  of  brightness  control. 

e  Requirements  for  feedback  controlled  display  brightness, 
e  Utility  of  reverse  video. 

/  Vision  . . .  color 

e  Utility  of  color  for  highlighting  and  attribute  encoding, 
e  Selection  of  colors  for  highlighting  and  attribute  encoding, 
e  Permissible  density/saturation  of  colors  in  displays. 

e  Requirements  for  alternatives  to  color  for  soldier/operator 
with  defective  color  vision. 

SPEECH  PATTERNS  AND 
CHARACTERISTICS 

e  Utility  of  speech  input  as  a  control  and  data  entry  device. 

v\ 


voice  input  approach.  Effects  of  stress  on  the  voices  of  the  crew  members  may 
also  have  a  bearing  on  the  acceptability  of  the  voice  input  approach. 

Additionally,  the  degree  of  vehicle  movement  and  jostling  that  may  be 
expected  during  combat  maneuvers,  could  encourage  system  developers  to  maxi¬ 
mally  reduce  the  number  of  terminal  keys  that  must  be  pressed  for  specific 
tactical  functions.  The  high  potential  for  errors  to  occur,  when  fine  motor 
movements  are  required  within  a  turbulent  vehicle,  may  influence  system  devel¬ 
opers  to  rely  on  control  methods  such  as  light  pens  and/or  joysticks. 

To  ensure  precise  measurement ,  analysis ,  and  feedback  of  crew  functional 
performance,  all  fine  motor  responses,  such  as  pressing  terminal  keys  and 
light  pen  movements,  should  be  recorded  by  the  system.  Furthermore,  any 
verbid  commands  to  the  system  could  also  be  documented.  These  recordings 
of  crew  responses  will  be  associated  with  the  specific  on-going  combat  scenar¬ 
ios  portrayed  by  the  training  module,  as  well  as  the  respective  functional 
areas.  Thus,  the  documentation  for  each  soldier's  response  will  identify: 

1.  The  general  combat  situation  during  the  soldier's  response. 

2.  The  displayed  peripheral  and  system  readings  to  which  the 
soldier  responded. 

3.  The  functional  area  addressed. 

The  following  list  indicates  the  type  of  functional  areas  for  which  the 
crew  will  be  responsible: 

1.  Various  control  methods. 

2.  Requests  for  specific  display  formats. 

3.  Data  entry  procedures. 

4.  Message  composition. 

5 .  Data  retrieval . 

6.  Specific  terminology  and  symbology. 

7.  Correcting  errors. 

A  cumulative  record  of  crew  activities  will  be  maintained  by  the  system 
and  assessed.  Comparing  soldier  responses  with  predetermined  performance 
criteria  will  provide  measures  of  the  degree  of  precision,  consistency,  change, 
and  ■improvement  in  soldier  performance.  Once  the  crew  demonstrates  proficiency 
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with  the  novice  level  training  modules ,  they  will  progress  to  the  more  advanced 
simulated  combat  modules. 

Peripheral  and  Vehicle  Sensor  Data 

The  sensor  data  that  will  be  displayed  by  the  combat  vehicle  computer 
system  will  be  combined  to  portray  a  hierarchical  series  of  combat  scenarios. 

As  previously  discussed,  Tables  A-l  through  A-9  list  the  types  of  information 
that  will  be  read/displayed  to  the  crew.  The  displays  will  portray  combat 
situations,  and  require  soldier  action  in  response. 


Performance  Prompts  and  Instructions 

Vetronics  has  the  capability  to  provide  response  prompts  to  novice 
trainees,  as  well  as  to  more  eaqperienced  vehicle  operators  during  periods  of 
memory  loss,  confusion,  fatigue,  and/or  stress.  The  number  and  type  of  prompts 
required  or  requested  may  be  recorded  and  used  during  the  assessment  of  crew 
mastery  of  vehicle  operating  procedures. 

System  prompts  and  instructions  for  the  crew  may  be  provided  via: 

1 .  Aural  messages . 

2.  Textual  messages  on  display  screens. 

3.  Abbreviations  or  codes  via  display  screens. 

4.  Series  of  blinking  lights  or  beeping  sounds. 

Although  battle  conditions  may  preclude  the  use  of  aural  or  extended  textual 
messages,  codes  and  abbreviated  textual  messages  could  be  useful. 

Performance  Feedback 

Following  the  recording  and  analysis  of  soldier  performance  against 
preestablished  accuracy  and  speed  criteria,  system-generated  performance 
feedback  may  be  communicated  to  the  crew.  The  types  of  evaluative  feedback 
might  include: 

1.  Degree  of  response  accuracy. 

2 .  Dichotomous  correct  or  incorrect  response  assessments . 
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3.  Response  consistency  or  reliability. 

4.  Response  amplitude. 

5.  Reaction  time. 

6.  Rate  of  responding. 

7.  Instant  replay  or  listing  of  response  sequence  (e.g.,  within 
the  past  5  or  10  minutes  or  since  a  specific  message  was 
displayed) . 

The  system  may  also  be  programmed  to  provide  correct  responses,  once  a 
soldier  has  been  informed  of  an  error.  Additional  feedback  capabilities 
include  notifying  the  soldier,  via  textural  or  graphic  representation  of  the 
environmental,  vehicle,  and/or  personal  consequences  of  these  activities — e.g. 
soldier's  death,  combat  vehicle  exploded,  or  vehicle  weapon  successfully 
exploded  another  vehicle.  The  system  could  also  include  an  instructor  "freeze 
capability  to  permit  specific  live  tutorial  action.  To  accentuate  the  degree 
of  emotionalism  affiliated  with  extreme  simulated  environmental  or  personal 
consequences,  flashing  red  lights  or  aversive  buzzers  might  be  added. 

RECOMMENDATIONS 

1.  Specific  soldier-machine  interface  recommendations  cited 
in  the  previous  section,  such  as  appropriate  applications 
of  voice  input,  light  pens,  or  joysticks,  are  discussed 
in  greater  detail  in  the  Prototype  Handbook.  Sections  of 
the  Prototype  Handbook  relating  to  control  methods  and 
guidelines  that  enable  system  input  capabilities  for  crew 
members  during  on-board  training  include: 

1.1  Alphanumeric  Control  Methods 

1.2  Graphics  Contol  Methods 

1.3  HELPS 

3.1  Information  on  Legal  Entries 

3.2  Unburdening  of  Input 

3.3  Interrupts  and  Work  Recovery 

5.1  Query  Method 

5 . 2  Query  Structure 

6.1  Symbols  and  Symbol  Sets 


6 . 2  Standard  Terms 


6.3  Abbreviations  and  Codes 


6.4  Full  Language 

7.2  Error  Correction  and  Recovery 

Sections  of  the  handbook  relating  to  display  methods  for 
on-board  training  modules  are: 

2.1  Alphanumeric  Displays 


2.2  Graphics  Displays 

2.3  Selective  Highlighting 

4.1  Composition  Aids  for  Alphanumeric  Messages 

4.2  Composition  Aids  for  Graphics  Displays 


6.1  Symbols  and  Symbol  Sets 


6 . 2  Standard  Terms 


6.3  Abbreviations  and  Codes 


7.1  Error  Feedback 
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This  effort  to  analyze  design  issues  related  to  the  soldier-machine 
interface  of  selected  of  the  Vetronics  capabilities,  and  to  develop  recommen¬ 
dations  based  on  the  Prototype  Handbook  for  Combat  and  Material  Developers 
to  resolve  a  set  of  SMI  issues,  has  occurred  at  a  very  early  stage  of 
Vetronics  development,  without  benefit  of  any  design  specifications.  The 
analyses  presented  here  are,  therefore,  tentative;  but  they  nonetheless 
demonstrate  that  Vetronics  poses  considerable  SMI  issues  due  to  the  magnitude 
and  complexity  of  the  data  it  will  handle.  Further,  the  additional  tasks 
Vetronics  imposes  on  the  crew  are  apt  to  be  disruptive  to  crew  performance 
if  they  are  not  fully  integrated  with  current  crew  responsibilities. 

In  addition  to  the  volume  of  data  Vetronics  will  deal  with,  the  volume 
of  transactions  anticipated  and  the  nature  of  the  environment  in  which  it 
will  operate,  pose  increased  demands  on  the  soldier's  intellectual  resources 
and  physical  stamina.  These  conditions  require  that  meaningful,  understand¬ 
able  information  be  presented  rapidly  and  that  correct  crew  interpretations 
be  obtained  quickly.  Delays  caused  by  the  need  to  ponder  an  ambiguous  display 
or  to  deliberate  over  input  commands  could  lead  to  the  actual  destruction  of 
the  vehicle  and  its  crew. 

The  analyses  presented  here  are  followed  by  recommendations  for  resolu¬ 
tion  of  SMI  issues  and  enhancement  of  the  interface.  In  addition  to  specific 
design  recommendations  based  on  content  of  the  Prototype  Handbook,  more 
general  guidance  is  provided  by  suggesting  relevant  sections  of  the  guidelines 
document  that  provide  guidance  appropriate  to  recommended  transactional 
features.  Table  4  summarizes  these  Prototype  Handbook  sections  for  selected 
of  the  intended  Vetronics  capabilities. 
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Table  4 


Summary  of  Recommended  Guidelines  for  Soldier-Machine  Interface 
Issues  of  Selected  Vetronics  Capabilities 

VETRONIC  CAPABILITY 


PROTOTYPE  HANDBOOK  SECTION 


1.  CONTROL  MEASURES 


1.1  Alpahnumeric  Control  Methods 


1.2  Graphics  Control  Methods 


1 .3  HELPS 


2.  DISPLAY  TECHNIQUES 


2.1  Alphanumeric  Displays 


2.2  Graphics  Displays 


2.3  Selective  Highlighting 


3.  DATA  ENTRY  AND  HANDLING 


3.1  Information  on  Legal  Entries 


3.2  Unburdening  of  Input 


3.3  Interrupts  and  Work  Recovery 


4.  MESSAGE  COMPOSITION  AIDS 


4.1  Composition  Aids  for  Alphanumeric  Messages 


4.2  Composition  Aids  for  Graphics  Displays 


5.  DATA  RETRIEVAL  ASSISTANCE 


5.1  Query  Method 


5.2  Query  Structure 


6.  SYMBOLOGY  AND  TERMINOLOGY 


6.1  Symbols  and  Symbol  Sets 


6.2  Standard  Terms 


6.3  Abbreviations  and  Codes 


6.4  Full  Language 


6.5  Glossaries 


7.  ERROR  HANDLING 


7.1  Error  Feedback 


7.2  Error  Correction  and  Recovery 
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Tactical  Situation 

Display 


Table  A-l. 

Data  Pertaining  to  Meteorological  Conditions 


SPECIFIC 

ELEMENT  OR 

ATTRIBUTE 

OF 

DATA 

UTILITY  OF  DATA  TO 

COMBAT  VEHICLE  CREWS 

DATA  SOURCE  jf 

STORED  IN  VEHICLE 

VEHICLE  SENSORS  (INT.) 

|  VFHICIE  SENSORS  (EXT.) 

VEHICLE  UNIT  COMMO 

LOCAL/REMOTE  SENSOR 

|  DIRECT  OOHNLINK 

REMOTE  SYSTEM  COMMO 

|  DERIVATIVE  (PROCESS) 

RAIN: 

Recent 

History 

Current 

Forecast 

e  Route  planning 

• 

• 

•  Maneuver  control 

• 

• 

•  Terrain  exploitation 

e 

•  Threat  assessment 

• 

• 

t 

•  Counter  measure  selection 

• 

• 

• 

a  Target  selection 

t 

• 

•  Terrain  exploitation 

• 

• 

•  Target  acoulsltlon 

• 

t 

• 

•  Fire  control 

9 

f 

e 

•  Route  planning 

• 

• 

e  Maneuver  control 

• 

• 

TEMPERATURE : 

Recent  hlstor; 

Current 

Forecast 

e  Route  planning 

• 

• 

e  Maneuver  control 

• 

• 

e  Threat  assessment 

• 

> 

e  Fire  control 

• 

■  Tarnet  iraultHton 

— 

== 

e  Route  planning 

• 

• 

e  Maneuver  control 

• 

A-l 


Table  A-l. 
(Continued) 


SPECIFIC 

ELEMENT  OR 

ATTRIBUTE 

UTILITY  OF  DATA  TO 

OF 

COMBAT  VEHICLE  CREWS 

DATA 

DATA  SOURCE 


SNOW: 

•  Route  planning 

•  • 

Recent  Histoij 

a  Maneuver  control 

•  JL. 

Current 

•  Threat  assessment 

• 

a  Counter  measure  selection 

• 

a  Target  selection 

• 

a  Terrain  exploitation 

• 

a  Target  acquisition 

• 

a  Fire  control 

• 

Forecast 

a  Route  planning 

•  • 

a  Maneuver  control 

•  t 

CURRENT 

a  Counter  measure  selection 

• 

WIND 

a  Target  acquisition 

• 

a  Fire  control 

• 

a  Tarqet  selection 

• 

CURRENT 

a  Terrain  exploitation 

t  ! 

FGG/SMOG 

a  Target  acquisition 

• 

a  Counter  measure  selection 

• 

a  Fire  control 

• 

DERIVATIVE  (PROCESS) 


Table  A-l. 
(Continued) 


SPECIFIC 

ELEMENT  OR 

ATTRIBUTE 

OF 

DATA 

UTILITY  OF  DATA  TO 
COMBAT  VEHICLE  CREWS 

DATA  SOURCE  | 

STORED  IN  TANK 

VEHICLE  SENSORS  (I NT.) 

VEHICLE  SENSORS  (EXT.) 

VEHICLE  UNIT  COMMO 

LOCAL/REMOTE  SENSOR 

DIRECT  DOWNLINK 

REMOTE  SYSTEM  COMMO 

DERIVATIVE  (PROCESS) 

CURRENT 

HUMIDITY 

•  Fire  control 

• 

•  Target  acquisition 

§ 

CURRENT 

BAROMETRIC 

PRESSURE 

e  Fire  control 

• 

e  Tarqet  acquisition 

B 

■ 

■ 

■ 

■ 

DERIVATIVE  (PROCESS) 


INFORMATION 

TYPE 


INFORMATION 

ATTRIBUTES 


SOLDIER-SYSTEM  INTERFACE 
APPLICATIONS 


NOISE 

•  Intensity 

e  Feasibility  of  audible  alarms  and  signals 
e  Required  levels  of  audible  alarms  and  signals 

e  Spectral  characteristics 

e  Optimum  frequency  for  audible  alarms  and  signals 
e  Filler  characteristics  for  voice  input 
e  Spectrum  for  voice  output 

e  Duration;  continuousness; 
predictability 

e  Requirements  for  multiple  Input/output  channels 

SMOKE;  HAZE 

e  Density 

e  Required  intensity  of  visual  displays 
e  Operator-to-di splay  distance  limits 

e  Persistence 

e  Requirer,*nts  for  varying  display  Intensity  levels 

e  Spectral  characteristics 
(reflection;  absorbtion) 

e  Required  color  of  visual  displays 

TEMPERATURE 

e  Level 

e  Design  of  controls  to  accomodate  to  physical  con¬ 
comitants  of  temperature  extremes: 

-  Perspiration 

-  Stiff,  numb  fingers  and  other  extremities 

e  Stability 

e  Requirements  for  design  of  controls  and  displays  to 
accomodate  a  wide  range  of  physical  concomitants  of 
temperature  extremes 

LIGHTING 

e  Intensity 

e  Required  Intensity  of  visual  displays 

e  Source 

e  Arrangements  of  visual  displays  to  eliminate/reduce 
"washout'' 

e  Requirements  for  reorientability  of  visual  displays  to 
accommodate  changing  illumination  sources 

e  Spectral  characteristics 

e  Requirements  for  color  of  visual  displays 

o  Requirements  for  color  of  reflected- light  markings  on 
controls  and  instructions 

•  Requlrmnents  for  color  of  printed  Job  aids 

e  Duration;  continuousness; 
predictability 

e  Requirements  for  variability  in  display  intensity  and 
orientation 

a  Requirements  for  automated  control  of  display 
intensity  and  orientation 

a  Requirements  for  variability  in  cont'ol  illumination 

Table  A-2. 
(Continued) 


INFORMATION 

TYPE 

INFORMATION 

ATTRIBUTES 

SOLDIER-SYSTEM  INTERFACE 

APPLICATIONS 

VIBRATION 

•  Intensity  (amplitude) 

•  Requirements  for  type  and  size  of  displays 

•  Requirements  for  design  and  Installation  of  control 
devices 

•  Period  (spectral  charaetlstlcs) 

e  Requirements  for  type  and  size  of  displays  (and 
elements  of  displays) 

e  Requirements  for  design  and  Installation  of  control 
devices 

•  Duration!  continuousness; 
predictability 

e  Requirements  for  variability  In  display  element  size 

e  Requirements  for  automated  control  of  display  element 
size 

e  Requirements  for  default  display  to  particular  device 
during  periods  of  high  vibration 

ACCELERATION 

•  Intensity 

e  Requirements  for  control  selection  and  design 
e  Requirements  for  display  positioning 

•  Duration;  continuousness; 
predictability 

e  Requirements  for  control  selection  and  design 
e  Requirements  for  display  positioning 

•  Requirements  for  acceleration— Induced  error 
correction 

e  Requirements  for  real-time  detection  of  acceleration 
forces  and  associated  suspenslon/alteratlon  of 
display/control/processing  activities 

•  Requirements  for  alternative  display /control  modes 

•  Direction 

e  Control  positioning  requirements 
•  Display  positioning  requirements 

Table  A-3. 

Data  Pertaining  to  Plans,  Routes,  and  Missions 


1 

SPECIFIC 

ELEMENT  Oft 

ATTRIBUTE 

OF 

DATA 

UTILITY  OF  DATA  TO 

COMBAT  VEHICLE  CREWS 

DATA  SOURCE  1 

STORED  IN  VEHICLE 

VEHICLE  SENSORS  (I NT.) 

VEHICLE  SENSORS  (EXT.) 

VEHICLE  UNIT  COMMO 

LOCAL/REMOTE  SENSOR 

|  DIRECT  DOWNLINK 

REMOTE  SYSTEM  COMMO 

DERIVATIVE  (PROCESS) 

BATTLE  PLAN 

•  Route  planning 

• 

• 

•  Scheduling 

• 

• 

•  Schedule  adherence  analysis 

• 

• 

•  Targeting  priority  assignment 

• 

• 

OBJECTIVES 

•  Route  planning 

• 

• 

•  Alternative  route  analysis 

• 

• 

t  Schedule  adherence  analysis 

• 

• 

e  Maneuver  control 

^ARGET^^^_ 

•  Targeting 

• 

CONTINGENCY 

PLANS 

•  Route  planning 

• 

• 

•  Assignment  of  resources 

• 

• 

•  Rescheduling 

• 

• 

•  Tlme-to-polnt  estimation 

> 

• 

RULES  OF 
ENGAGEMENT 

•  Target  priority  assignment 

• 

• 

•  Target  selection 

• 

• 

Table  A-4. 


Data  Pertaining  to-  Individual  Combat  Vehicles 


SPECIFIC 

ELEMENT  OR 

ATTRIBUTE 

UTILITY  OF  DATA  TO 

OF 

COMBAT  VEHICLE  CREWS 

DATA 

POSITION 

e  Route  planning 
e  Target  selection 
e  Target  acquisition 
e  Terrain  masking 
e  Analysis  of  terrain  attributes 

BEARING 

o  Warning  of  terrain  conflict 

e  Orientation'  re  other  forces 
•Friendly 
•Enemy 

e  Point  arrival  prediction 
e  Target  selection 
e  Target  acquisition 

VELOCITY 

e  Route  planning 

DATA  SOURCE 


£  6  ee 

—  uj  Q  o 

<->  l/l  l/l  O  Ul 

—  QC  QC  o  1/1 

X  o  o 

^  l/)  h  UJ 


UJ  o  U  U  J  U 

9£  —  —  1  <  UJ 

p  X  X  X  O  OH 

Lkj  UJ  UJ  o  M 

3*  >  >•  _J  O 


•  Timely  warning  of  terrain 
conflict 

e  Warning  of  exposure  to  enemy 
fire 

e  Point  arrival  prediction 
e  Time  to  refueling 
e  Target  selection  (predictive) 
e  Target  acquisition 
e  Target  trackln 


REMOTE  SYSTEM  COMMO 


Table  A-4. 
(Continued) 


SPECIFIC 

ELEMENT  OR 

ATTRIBUTE 

OF 

DATA 

UTILITY  OF  DATA  TO 

COMBAT  VEHICLE  CREWS 

DATA  SOURCE 

STORED  IN  VEHICLE 

VEHICLE  SENSORS  (I NT.) 

VEHICLE  SENSORS  (EXT.) 

VEHICLE  UNIT  COMMO 

LOCAL/REMOTE  SENSOR 

OIRECT  DOWN. INK 

REMOTE  SYSTEM  COMMO 

DERIVATIVE  (PROCESS) 

ATTITUDE 

Roll 

Pitch 

Yaw 

•  Target  acquisition 

•  Target  tracking 

•  Assessment  of  tank  performance 
envelope  performance 

•  Maneuver  planning 

•  Weapons  resource  allocation 

•  Fire  control 

1 

1 

1 

1 

1 

1 

1 

1 

WEAPONS  SYSTEM 
STATUS: 

Operabil  ity 

•  Weapons  system  resource 
allocation 

•  Fire  control 

1 

R 

1 

1 

1 

1 

1 

1 

Orientation 

(Asimuth/ 

Elevation) 


Temperature 


•  Target  selection 
t  Target  acquisition 


t  Target  selection 

•  Target  acquisition 

•  Fire  control 


•  Target  acquisition 

•  Fire  control 


Ammo  loaded 


•  Target  selection 

•  Target  acquisition 

•  Fire  control 


IMUA'A'AWIU'.U  <. 
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Table  A-4. 
(Continued) 


>.v 

L\ 


* 
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r.* 

fc 

I 
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oj 
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If 


£ 

*v 
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SPECIFIC 

ELEMENT  OR 

ATTRIBUTE 

OF 

DATA 

UTILITY  OF  DATA  TO 

COMBAT  VEHICLE  CREWS 

DATA  SOURCE  S 

STORED  IN  VEHICLE 

VEHICLE  SENSORS  (I NT.) 

VEHICLE  SENSORS  (EXT.) 

VEHICLE  UNIT  COMMO 

LOCAL/REMOTE  SENSOR 

DIRECT  DOWNLINK 

REMOTE  SYSTEM  COMMO 

DERIVATIVE  (PROCESS) 

SENSOR  STATUS: 

Operabil  ity 

Orientation/ 

Aim 

Performance 

•  Allocation  of  personnel  and 
processing  resources 

•  Threat  assessment 

•  Threat/Information  tradeoff 

• 

• 

•  Allocation  of  personnel  and 
processing  tradeoffs 

a  Target  Identification 

•  Target  acquisition 
e  Target  selection 

• 

•  Threat  assessment 

•  Selection  of  most  appropriate 
..data  source 

• 

PROPULSION 
SYSTEM  STATUS: 

Temperature 

Fuel  Flow 

a  Route  planning 
a  Maneuver  planning 
a  Time  to  reach  designated  point 
e  Predicted  system  failure  point 

• 

= 

e  Operating  radius 
e  Predicted  vs.  actual  performance 
e  Route  planning 
e  Maneuver  planning 
e  Maintenance  indicator 

• 

A-9 


Table  A-4. 
(Continued) 


i*n©rj 


Vi'r. 


DERIVATIVE  (PROCESS) 


V*  -w' 


SPECIFIC 


ELEMENT  OR 
ATTRIBU'E 


ELECTRICAL  A 
ELECTRONICS 
SYSTEMS  STATUS: 


Availability 


AMMUNITION 

STATUS: 


Available 

Types 


Amount 


AMMUNITION 

STATUS: 


Usage  Rate 


Table  A-4. 


(Continued) 


UTILITY  OF  DATA  TO 


COMBAT  VEHICLE  CREWS 


COUNTERMEASURES 
STATUS  (Cont.) 
Orientation/ 
Aim 


e  Threat  assessment 
a  Target  selection 
e  Maneuver  control 


e  Threat  assessment 
e  Target  selection 
e  Maneuver  planning/control 


e  Threat  assessment 
e  Personnel /processor  tasking 
e  Decision  process  allocation 
e  Capabilities  assessment  and 


prediction 


•  Target  selection 

•  Maneuver  planning  and  control 
e  Route  planning 

a  Weapons  resource  allocation 


e  Target  selection 
e  Maneuver  planning  and  control 
e  Route  planning 
•  Weapons  resource  allocation 


e  Estimation  of  useful  opera¬ 
tional  radius  and  tenure 


e  Route  planning 
•  Target  selection 
e  Maneuver  planning  and  control 


DATA  SOURCE 


S  S-  g  S 
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DERIVATIVE  (PROCESS) 
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Table  A- 4. 
(Continued) 


DATA  SOURCE 


SPECIFIC 
ELEMENT  OR 
ATTRIBUE 
OF 

DATA 


UTILITY  OF  DATA  TO 
COMBAT  VEHICLE  CREWS 


'->(/}</>  O  u 

5  g  g  w  *»  * 

£  £  £  £  £  * 

UJ  Z  o  s 

z  oo  wo  =>  3t  C 

M  Ui  O 

Ui  uJ  UJ  OC 

S  u  u  d  j  t 

Sir  z  S  k 

t—  uj  uj  uj  o  m 

w  2  o 


FUEL,  LUBRICANT, 
AND  COOLANT: 

Amount 


Usage  Rate 


•  Estimation  of  operational  radius 
and  tenure 

e  Route  planning 

e  Maintenance  planning 

e  Maneuver  planning  and  control 


e  Estimation  of  operational  radius 
and  tenure 

•  Route  planning 

e  Maintenance  planning 

e  Maneuver  olannln 


VEHICLE  PERFOR- 

e  Comparison  to  actual  vehicle 

MANCE  CAPABIL- 

behavior 

ITIES 

e  Comparison  to  terrain 

Speed 

e  Real-time  comparison  with 

Maneuver- 

vehicle  situation 

ability 

Grades 

Trenches 

Range 

Attitude 

REMOTE  SYSTEM  COMMO 


Table  A-4. 
(Continued ) 


DATA  SOURCE 


SPECIFIC 
ELEMENT  OR 
ATTRIBUTE 
OF 

DATA 


UTILITY  OF  DATA  TO 
COMBAT  VEHICLE  CREWS 


o 

f— 

V> 


WEAPON  PERFOR¬ 
MANCE  CAPABIL¬ 
ITIES: 

•Train  Rate 
•Elevation 
•Range 
•Accuracy 
•Kill  Prob. 


e  Target  selection 
e  Maneuver  control 
e  Terrain  utllltatlon/avoldance 
e  Route  planning 


•Target  Type 
Dependencies 


DEFE16IVE  e  Route  planning 

SYSTEM  PERFOR¬ 
MANCE  CAPABIL-  e  Target  selection 
ITIES: 


•Armor  Eff- 


e  Maneuver  control 


ectlveness 


•Jamming 

•Other 


DERIVATIVE  (PROCESS) 


Table  A- 5 


Data  Pertaining  to  Combat  Vehicle  Platoon  or  Other  Unit 


SPECIFIC 

ELEMENT  OR 

ATTRIBUTE 

OF 

DATA 

UTILITY  OF  DATA  TO 

COMBAT  VEHICLE  CREWS 

DATA  SOURCE  | 

STORED  IN  VEHICLE 

VEHICLE  SENSORS  (INT.) 

|  VEHICLE  SENSORS  (EXT.) 

|  VEHICLE  UNIT  COMMO 

|  LOCAL/REMOTE  SENSOR 

* 

5 

1 

u 

s 

1  REMOTE  SYSTEM  COMMO 

t/> 

%/> 

UJ 

o 

s 

& 

UJ 

a» 

5 

> 

s 

£ 

MISSION  DATA: 
Objective 
Locati on 

Objective 

Type 

Primary 

Route 

Alternative 

Routes 

Critical 

Maneuver 

Points 

•  Route  planning 

• 

• 

• 

•  Mission  planning 

• 

• 

•  Maneuver  control 

• 

• 

• 

e  Weapons  allocation 

• 

•  Target  acquisition 

•  Route  planning 

t 

•  Performance  envelope  planning 

• 

o  Route  planning 

• 

e  Performance  envelope  planning 

• 

• 

= 

e  Route  planning 

• 

• 

e  Maneuver  planning 

• 

• 

• 

• 

a  Contingency  route  planning 

• 

• 

• 

t 

POSITION 
RELATIVE  TO 
OTHER 

VEHICLES 

e  Maneuver  control 

"V 

i • 

e  Joint  target  selection 

• 

• 

• 

e  Target  identification 

• 

• 

• 

e  Sensor  optimization 

• 

• 

> 

FIELD  OF 

FIRE 

e  Joint  target  selection 

• 

• 

• 

• 

e  Threat  evaluation 

• 

• 

• 

• 

A-14 


SPECIFIC 
ELEMENT  OR 
ATTRIBUTE 


UTILITY  OF  DATA  TO 
COMBAT  VEHICLE  CREWS 


VEHICLE  UNIT 
COMPOSITE 
STATUS : 


Weapons 

System 


Sensor 

Systems 


Counter¬ 

measure 

Status 


Position  and 
Orientation 


a  Target  selection 


•  Maneuver  planning  and  control 


•  Resource  allocation 


a  Tank  placement  and  assignment 


e  Target  selection 


e  Maneuver  planning  and  control 


a  Route  planning 


e  Threat  assessment 


e  Maneuver  planning  and  control 


e  Route  plannln 


e  Threat  assessment 


Electrical  S 
Electronics 
System  Statu 


s  St 


DATA  SOURCE 


£  M 

£  5 

8  S 

UJ  & 


a  Target  selection 


e  Joint  target  acquisition 


•  Maneuver  planning  and  control 


e  Terrain  capitalization 


e  Target  selection 


e  Threat  assessment 


a  Maneuver  planning  and  control 


o  Vehicle  placement  and  role  assignment 


DERIVATIVE  (PROCESS 


Table  A-5. 
(Continued) 


SPECIFIC 

ELEMENT  OR 

ATTRIBUTE 

OF 

DATA 

UTILITY  OF  DATA  TO 

COMBAT  VEHICLE  CREWS 

DATA  SOURCE  1 

STORED  IN  VEHICLE 

|  VEHICLE  SENSORS  (INT.) 

VEHICLE  SENSORS  (EXT.) 

VEHICLE  UNIT  COMMO 

LOCAL/REMOTE  SENSOR 

DIRECT  DOWNLINK 

REMOTE  SYSTEM  COMMO 

DERIVATIVE  (PROCESS) 

VEHICLE  UNIT 
COMPOSITE 
STATUS (Cont.): 

Propulsion 
System  Statu! 

e  Threat  assessment 

m 

B 

•  Maneuver  planning  and  control 

D 

B 

•  Vehicle  placement  and  assignment 

a 

B 

•  Target  selection 

a 

B 

Ammunition 

Status 

t  Threat  assessment 

a 

D 

•  Target  selection 

a 

n 

•  Vehicle  placement  and  assignment 

a 

□ 

■ 

•  Target  selection 

n 

R 

e  Vehicle  placement  and  assignment 

R 

R 

e  Default  operations 

a 

H 

Table  A-6. 

Data  Pertaining  to  Friendly  Forces 


DATA  SOURCE 


SPECIFIC 
ELEMENT  OR 
ATTRIBUTE 
OF 

DATA 


UTILITY  OF  DATA  TO 
COMBAT  VEHICLE  CREWS 


(Si  CO 

S  fie-  ££ 

5  o  o 

>  z  z 


TYPE  OF  FORCE 

OR  EQUIPMENT: 

e  Mission  planning  and  execution 

Infantry 

•  Route  planning 

Armor 

•  Threat  assessment 

Artillery 

ADA 

•  Target  selection 

Anti-tank 

Helo 

FW  A/C 

Sensors 

Log/Supply 

•  Target  Identification 

•  Route  planning 


•  Threat  assessment 


•  Target  Identification 


•  Target  selection 


•  Fire  control 


•  Threat  assessment 


•  Target  identification 


•  Fire  control 


REMOTE  SYSTEM  COMMO 


Table  A- 6 


(Continued) 


SPECIFIC 

ELEMENT  OR 

ATTRIBUTE 

OF 

DATA 

UTILITY  OF  DATA  TO 

TANK  CREWS 

DATA  SOURCE 

STORED  IN  VEHICLE 

VEHICLE  SENSORS  (INT.) 

VEHICLE  SENSORS  (EXT.) 

VEHICLE  UNIT  COMMO 

LOCAL/REMOTE  SENSOR 

DIRECT  DON  M.  INK 

REMOTE  SYSTEM  COMMO 

DERIVATIVE  (PROCESS) 

BEARI NG 

•  Threat  assessment 

• 

• 

■ 

■ 

D 

D 

•  Fire  control 

• 

• 

D 

□ 

e  Route  planning 

• 

• 

n 

e  Maneuver  plannlnq  and  control 

> 

• 

n 

n 

ASSOCIATED 

EQUIPMENT: 

Weapons 

Commo 

Sensors 

Supplies 

e  Mission  coordination 

• 

• 

e  Threat  assessment 

H 

H 

1 

H 

R 

H 

H 

•  Target  selection 

H 

■ 

1 

■ 

H 

R 

R 

H 

e  Route  and  maneuver  control 

D 

■ 

1 

■ 

B 

R 

fl 

1 

LOCAL/RENOTE  SENSOR 


Table  A-7. 

Data  Pertaining  to  Enemy  Forces 


SPECIFIC 

ELEMENT  OR 

ATTRIBUTE 

OF 

DATA 

UTILITY  OF  DATA  TO 

COMBAT  VEHICLE  CREWS 

DATA  SOURCE  1 

|  STORED  IN  VEHICLE 

VEHICLE  SENSORS  ( 1NT. ) 

VEHICLE  SENSORS  (EXT.) 

VEHICLE  UNIT  COMMO 

LOCAL/REMOTE  SENSOR 

|  DIRECT  DOWNLINK 

REMOTE  SYSTEM  COMMO 

DERIVATIVE  (PROCESS) 

TYPE  OF  FORCE/ 
EQUIPMENT: 

Armor 

Helo 

Artillery 

Infantry 

Anti-tank 

FW  A/C 

Sensors 

Supply 

ADA 

•  Route  planning 

• 

• 

• 

• 

•  Maneuver  planning  and  control 

• 

• 

• 

• 

t  Target  selection 

• 

• 

•  Threat  assessment 

• 

• 

•  Terrain  exploitation 

• 

t 

POSITION 

•  Route  planning 

t 

e  Threat  assessment 

t 

0 

0 

0 

0 

•  Target  Identification 

• 

0 

0 

0 

0 

•  Target  selection 

• 

0 

0 

0 

0 

•  Target  acquisition 

• 

0 

0 

0 

0 

•  Fire  control 

t 

0 

0 

0 

0 

•  Terrain  exploitation 

• 

0 

0 

0 

0 

SPEED 

•  Maneuver  planning  and  control 

• 

• 

•  Threat  assessment 

• 

• 

•  Target  Identification 

• 

• 

e  Target  selection 

• 

e  Target  acquisition 

• 

e  Fire  control 

a  Terrain  exololtatlon 

r 


A-19 


Table  A-7. 
(Continued) 


DATA  SOURCE 


SPECIFIC 
ELEMENT  OR 
ATTRIBUTE 
OF 

DATA 


UTILITY  OF  DATA  TO 
COMBAT  VEHICLE  CREWS 


BEARING 


PROJECTED 

POSITION 


WEAPOWY: 

Range 


Rate  of  Fire 


Accuracy 


e  Threat  assessment 

•  Target  Identification 

•  Target  selection 

a  Target  acquisition 

•  Fire  control 

e  Terrain  exploitation 


e  Maneuver  control 
a  Threat  assessment 

t  Route  planning _ 

a  Fire  control _ 

a  Target  acquisition 
a  Maneuver  control 
a  Threat  assessment 
a  Terrain  exploitation 
a  Maneuver  control 
a  Threat  assessment 
a  Terrain  exploitation 
a  Threat  assessment 
a  Terrain  exploitation 


M. 


h-20 


DERIVATIVE  (PROCESS) 
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Table  A- 7. 
(Continued) 


DATA  SOURCE 


SPECIFIC 
ELEMENT  OR 
ATTRIBUTE 


UTILITY  OF  DATA  TO 
COMBAT  VEHICLE  CREWS 
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is 


WEAPONRY 
(Cont.): 
Accuracy 
(Cont. ): 

Orientation 


Reaction/ 

Response 


Associated 

Sensors/Fire 

Control 


•  Maneuver  control 


•  Target  selection 


•  Threat  assessment 


a  Target  selection 


a  Terrain  exploitation 


a  Terrain  exploitation 


•  Threat  assessment 


•  Target  selection 


•  Threat  assessment 


•  Target  selection 


a  Cover  exploitation 


a  Sensor  utilization 


a  Countermeasures  employment 


VEHICLE/PLATFORM 
CAPABILITIES:  \ 


a  Threat  projectlon/assessment 

a  Position  projection _ 

a  Terrain  exploitation 
a  Maneuver  control 
a  Target  selection 


Table  A-7. 
(Continued) 


Table  A- 7. 
(Continued) 


SPECIFIC 
ELEMENT  OR 

ATTRIBUTE  •  UTILITY  OF  DATA  TO 

0F  COMBAT  VEHICLE  CREWS 

DATA 


SENSOR  CHARAC¬ 
TERISTICS  AND 


CAPABILITIES  •  Maneuver  control 
(Cont.): 


Range  e  Target  selection _ 

e  Threat  assessment _ 

^Terralnexigloltatlon^^^ 
Vulnerability  e  Countermeasures  utilization 


to  Counter¬ 


measures  |  e  Maneuver  control 
Position 

e  Maneuver  control _ 

e  Threat  assessment _ 

e  Terrain  exploitation _ 

e  Cover  exploitation 
e  Countermeasures  application 
•  Target  Identification 
e  Target  selection 
e  Target  acquisition 
e  Fire  control 


e  Route  planning 


UNIT 

DESIGNATION 


t  Route  planning 
e  Maneuver  control 
e  Threat  assessment 


REMOTE  SYSTEM  COMMO 


Table  A-8 


Data  Pertaining  to  External  Physical  Environment 


DATA  SOURCE  I 

SPECIFIC 

ELEMENT  OR 

ATTRIBUTE 

OF 

DATA 

UTILITY  OF  DATA  TO 

COMBAT  VEHICLE  CREWS 

STORED  IN  VEHICLE 

VEHICLE  SENSORS  (INT.) 

VEHICLE  SENSORS  (EXT.) 

VEHICLE  UNIT  COMMO 

LOCAL/REMOTE  SENSOR 

DIRECT  DOWNLINK 

|  REMOTE  SYSTEM  COMMO 

in 
i n 

U J 

u 

o 

oc 

o. 

UJ 

> 

1 

1—1 

or 

& 

RADIO: 

e  Threat  assessment 

• 

• 

Frequency 

e  Target  Identification 

• 

• 

Intensity 

e  Maneuver  control 

• 

e  Route  Planning 

• 

e  Target  selection 

• 

e  Target  acquisition 

t 

e  Weapons  orientation 

• 

Bearing 

e  Route  planning 

~9~ 

e  Maneuver  control 

9 

e  Target  selection 

9 

e  Target  acquisition 

9 

e  Weapons  orientation 

9 

Modulation 

Character¬ 

istics 

e  Target  Identification 

• 

■ 

n 

e  Threat  assessment 

9 

■ 

B 

RADAR: 

e  Target  Identification 

9 

• 

Frequency  or 
Band 

e  Threat  assessment 

9 

• 

Modulation 

e  Target  Identification 

9 

9 

Characteristic 

a  Threat  assessment 

9 

9 

Table  A-8 


( Continued) 


DATA  SOURCE 


SPECIFIC 
ELEMENT  OR 
ATTRIBITE 
OF 

DATA 


UTILITY  OF  DATA  TO 
COMBAT  VEHICLE  CREWS 


RADAR  (cont.): 
Sweep/Scan 
Rate 

Intensity 


Bearing 
(Vector  to 
source) 


a  Target  Identification 
e  Threat  assessment 
e  Route  planning 

•  Maneuver  control 

e  Target  selection _ 

e  Target  Identification 
e  Counter  Measures  selection 
e  Route  planning 
e  Maneuver  control 
e  Target  selection 

•  Target  acquisition 

•  Weapons  orientation 

•  Countermeasures  orientation 


RADIATION: 

Frequency 

Distribution 

Intensity 


e  Target  Identification 

•  Threat  assessment 

•  Target  Identification 


•  Threat  assessment 


t 


DATA  SOURCE 


SPECIFIC 
ELEMENT  OR 
ATTRIBUTE 


UTILITY  OF  DATA  TO 
COMBAT  VEHICLE  CREWS 


OO  t/)  p  LU 

0£  QC  *->  l/> 
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UJ  ^ 
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I—  UJ  J 
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uj  oe 


U  o  w 
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•  Part  1  provides  an  overview  of  the  VIDS-DMS  for  the  benefit  of  readers 
who  are  not  familiar  with  the  system.  Part  2,  Analysis  and  General 
Findings,  describes  the  techniques  used  to  analyze  the  system's  software 
modiles  and  processes  and  discusses  global  issues  in  the  design  of  the 
soldier /machine  interface.  Part  3,  Modules  and  Processes, ,  addresses 
each  module  or  process  separately,  presenting  a  brief  functional  descrip¬ 
tion,  implications  for  the  soldier /machine  interface  and  recommendations 
to  resolve  design  issues.  Part  4  contains  a  summary  of  design  issues 
and  recommendations. 

Overview  of  the  VIDS-DMS 

The  US  Army  Development  and  Readiness  Command  (DARCOM) ,  through  the 
Concepts  Laboratory  at  the  Research  and  Development  Center  of  its  Tank- 
Automotive  Command  (TACOM) ,  is  developing1  self-protection  systems  for  ground 
combat  vehicles.  The  focus  of  this  effort  is  the  Vehicle  Integrated  Defense 
System  -  Data  Management  System  (VIDS-DMSO)  whose  general  design  concept  is 
illustrated  in  Figure  1.  Current  plans  call  for  the  design,  development, 
and  test  of  a  Feasibility  Demonstration  Model  (FDM)  of  the  VIDS-DMS,  which 
will  emphasize  the  data  management  aspects  of  the  system.*  The  DMS  will 
provide  a  data  processing  and  distribution  system  to  coordinate,  the  VIDS's 
threat  warning  sensors,  threat  reaction  devices,  and.  crew  interaction  sub¬ 
systems.  Signals  from  the  system's  sensor-s  will  be  processed  to  detect, 
locate,  and  classify  threats.  Self-protection  algorithms  will  compare  these 
threats  against  standards  and  priorities  stored  in  internal  files  and  tables 

Other  algorithms,  containing  recommended  reactions  as  well  as  threat  classi¬ 
fication  and  locations  information1,  will  display  warnings  to  the  crew.  The 
crew  in  turn  will  instruct  the  IMS  to  initiate  countermeasure;.,  either  by 
approving  the  system's  recomnendation  or  by  -specifyiftg  another  reaction.  In 
the  FDM,  sensor  inputs  and  reaction  outputs  will  be  simulated  to  provide  a 
feasibility  demonstration.  In  addition,  available  devices  will  be  used  to 
simulate  the  crew  display  and  control  unit. 


ANALYSIS  AND  GENERAL  FINDINGS 


Overview 

TVo  primary  sources  provided  data  for  the  analysis  of  SMI  issues  in 
VIDS-DMS  software  modules  and  processes:  VIDS-DMS  developer  personnel,  and 
the  draft  Procurement  Specification  cited  earlier.  Interviews  and  study  of 


the  document  revealed  that  the  FDM's  operational  software  will  consist 
essentially  of  an  executive  and  nine  functional  modules.  As  shewn  in  Figure 
2,  six  of  these  modules  are  divided  into  subordinate  processes  which  serve 
specific  purposes  within  the  overall  purpose  of  the  parent  module.  Each 
module  and/or  process  was  analyzed  for  implications  concerning  the  FDM's  SMI, 
and  recommendations  to  resolve  SMI  design  issues  were  developed.  The  analysis 
procedure  and  general  findings  are  discussed  immediately  belcw;  individual 
modules  and  processes  are  discussed  in  the  following  section. 

Procedure 

For  each  module  or  process,  analysis  consisted  of  first  preparing  a 
flow  chart.  This  chart  does  not  attempt  to  represent  the  structure  or 
operation  of  the  module  or  process  per  se .  Instead,  it  shows  the  module’s 
or  process's  inputs  and  outputs,  its  relationship  to  other  modules  or 
processes,  and  points  of  interaction  with  the  crew.  Thus,  flow  charts 
presented  in  the  next  section  are  drawn  at  a  relatively  general  level, 
which  nonetheless  is  adequate  to  the  needs  of  this  project. 


The  next  step  in  the  analysis  required  preparation  of  a  functional 
description  of  the  module,  based  upon  information  extracted  from  the  draft 
Procurement  Specification,  obtained  from  developer  personnel  at  TACOM , 


or  derived  from  the  flow  chart.  The  description  serves  two  purposes: 

1.  It  documents  the  contractor's  understanding  of  system 
software  functions. 


»Vp 


2.  It  provides  an  overview  of  the  module  or  process  for 
the  benefit  of  readers  unfamiliar  with  the  VXDS-DMS. 


The  analyst  then  described  SMI  implications  of  the  module's  or  process's 
points  of  interaction  with  the  crew.  This  discussion  noted  types  of  inter¬ 
actions  likely  to  be  required  and,  where  possible,  tasks  likely  to  be  im¬ 
posed  on  the  crew.  Finally,  the  analyst  developed  recommendations  to 
resolve  selected  issues  implied  by  the  analysis,  and  suggested  sections  of 
the  Prototype  Handbook  containing  guidance  relevant  to  that  issue . 

Because  of  limited  resources,  the  analysis  normally  ended  with  these 
suggestions.  However,  to  provide  more  detailed  examples  of  the  use  of 
the  Handbook,  in  two  cases  the  analysis  was  carried  further.  Application 
topics  and  interaction  methods  were  discussed,  drawing  upon  a  specific 
guideline  subsection.  Then,  the  subsection's  matrix  of  applications 
versus  methods  was  reproduced,  and  the  method  appropriate  to  the  specific 
VIDS-DMS  application  was  pointed  out.  This  extended  discussion  of  guide¬ 
lines  was  provided  for  the  Failure  Reconfiguration  Process  and  for  the 
Status  Fault  Check  Process. 


General  Findings 


VOLUME  OF  INTERACTION 


In  contrast  with  other  systems  analyzed  during  Synectics'  earlier 
contract  with  ARI,  the  VIDS-DMS  apparently  will  require  minimal  interaction 
with  the  crew.  Sensor  data  will  be  transmitted  automatically  from  peripheral 
devices  to  the  DMS ,  where  they  will  be  processed  and  evaluated  automatically, 
ordinarily  without  the  need  even  for  advice  from  the  crew.  Similarly,  threats 
will  be  detected,  located,  classified,  and  prioritized,  and  recommended 
reactions  will  be  developed  without  crew  interaction.  Thus,  system  communica¬ 
tions  with  the  crew  typically  will  be  conducted  on  an  exception  basis,  as 
for  example  when  a  threat  reaction  must  be  approved  or  when  a  failed  periph¬ 
eral  must  be  removed. 

The  decision  to  take  this  approach  to  system-crew  interaction  is  proba¬ 
bly  wise.  The  VIDS-DMS  will  be  installed  on  a  platform  whose  movement  over 


terrain  will  affect  crew  members'  abilities  to  perform  accurate  physical 
actions  such  as  pressing  keys  and  pointing  light  pens.  Combat  will  add 
confusion,  noise,  and  high  levels  of  stress.  In  this  chaotic  environment, 
crews  will  be  required  to  make  sound  decisions  rapidly,  choosing  from  a  limited 
number  of  fixed  alternatives  often  based  on  incomplete  or  uncertain  informa¬ 
tion.  Given  these  conditions,  they  must  not  be  required  to  master  and  use 
complex  command  languages,  extensive  interactive  procedures,  or  other  sophis¬ 
ticated  computer  skills  in  the  bargain. 

There  is  another  important  reason  to  adopt  a  "minimalist"  approach  to 
SMI  design  for  the  VIDS-DMS.  The  system  offers  great  potential  for  enhancing 
vehicle  and  crew  survival,  but  to  provide  that  enhancement  it  exacts  a  price: 
the  system  will  add  tasks  to  the  workload  of  at  least  one  vehicle  crew  member. 
These  tasks  must  be  integrated  very  carefully  into  the  current  duties  of  the 
affected  crew  jobs.  Otherwise,  performing  VIDS-DMS  tasks  may  conflict  with 
other  tasks ,  or  overburden  one  or  more  crew  members .  The  consequences  of 
such  an  outcome — degraded  crew  performance — might  well  defeat  the  very  purpose 
the  VIDS-DMS  was  designed  to  serve. 

DESIGN  OF  TRANSACTIONS 

Reduced  levels  of  interaction  in  the  VIDS-DMS  as  compared  with  many  other 
battlefield  automated  systems  does  not  reduce  the  requirement  for  care  in  the 
development  of  its  SMI.  Tasks  must  be  structured  to  ensure  that,  while 
accomplishing  the  system's  purposes,  they  are  reduced  to  the  minimum  number 
absolutely  required.  Performance  of  these  tasks  must  not  interfere  with  or 
detract  from  the  timely,  accurate  performance  of  other  important  crew  activi¬ 
ties.  Furthermore,  the  design  of  these  tasks  must  be  as  simple  and  straight¬ 
forward  as  possible,  to  avoid  imposing  unnecessary  additional  skill  requirements 
on  the  crew.  Also,  equipment  and  transaction  procedures  must  be  designed  to 
ensure  that  tasks  that  have  been  carefully  developed  in  accordance  with  these 
principles  will  not  be  disrupted  by  inconsistent,  inappropriate,  or  inconve¬ 
nient  SMI  design  features. 

Information  to  be  presented  on  displays  must  be  selected  in  accordance 
with  rigid  criteria  of  relevance  and  need,  so  that  all  essential  information — 
but  only  essential  information- -reaches  the  crew.  Of  course,  individual 
information  elements  must  also  reach  the  crew  at  the  times  they  are  needed. 


Moreover,  presentation  formats  must  be  designed  to  present  that  information 
logically,  in  the  sequence  that  it  will  be  used,  and  in  arrangements  on  the 
display  that  facilitate  rapid,  accurate  interpretation  and  understanding.  At 
the  same  time,  input  methods  for  command  and  data  entry  must  be  kept  as  simple 
as  possible,  and  be  designed  for  fast,  easy  entry  while  keeping  opportunities 
for  crew  members  to  commit  errors  to  the  minimum. 

In  this  project,  issues  such  as  these  could  not  be  explored  as  thoroughly 
or  in  the  depth  that  they  clearly  require.  Certainly,  they  should  be  given 
careful  and  continuous  attention  throughout  VIDS-DMS  development,  beginning 
as  early  as  possible.  Meanwhile,  the  following  section  provides  2m  initial 
analysis  of  specific  SMI  issues  in  the  system's  modules  and  processes,  and 
suggests  resolutions  for  some  of  these  issues.  Ihis  document  therefore  may 
serve  as  a  starting  point  for  the  more  extensive  effort  that  must  be  performed 


MODULES  AND  PROCESSES 


Power  Up  Module  and  Initial  Configuration  Process 

Description 

The  Power  Up  Module  and  the  Initial  Configuration  Process,  illustrated 
in  Figure  3,  are  discussed  jointly  here,  for  two  reasons: 

1.  They  apparently  never  operate  independently;  the  Initial 
Configuration  Process  is  not  invoiced  unless  the  Power  Up 
Module  has  been  invoked  first. 

2.  The  Power  Up  Module  and  initial  Configuration  Process  are 
both  invoked  in  only  one  situation:  when  power  is  first 
applied  to  the  system. 

The  VIDS-DMS  employs  a  typical  "cold  start"  procedure.  That  is,  the  Power  Up 
Module  is  called  by  a  hardware  interrupt  that  is  generated  automatically  when 
the  system  initially  receives  electrical  power.  The  Power  Up  Module  reads  in 
all  the  system's  program  and  data  files  and  then  requests  the  Configuration 
Module,  which  in  turn  invokes  the  Initial  Configuration  Process. 

The  Initial  Configuration  Process  uses  data  from  the  Initial  Configuration 
Selection  Tables  and  from  the  Peripheral  Status  and  Vehicle  Data  Files  to  set 
up  the  system's  operational  configuration  of  sensors,  reaction  devices,  and 
data  processing  capabilities.  It  stores  the  appropriate  data  in  the  Configura¬ 
tion  Status  File  for  use  by  other  modules  and  processes,  and  then  generates 
an  output  to  the  Control  Panel  Output  File. 

Soldier-Machine  Interface  Implications 

The  only  requirement  for  the  Power  Up  Module  appears  to  be  an  "ON/OFF" 
switch  (the  simplest  type  of  crew  "input")  and  some  form  of  positive  feedback, 
such  as  an  indicator  light  above  the  switch  or  a  light  behind  the  switch 
itself. 

The  Initial  Configuration  Process's  concluding  output  to  the  Control 
Panel  Output  File  clearly  contains  a  message  to  the  crew.  The  draft 
Procurement  Specification  does  not  describe  this  message;  presumably  it 
notifies  the  crew  that  the  system  is  ready  for  use. 
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Figure  3.  Schematic  of  System  Functions  Involving  the  Power  Up  Module  and 
the  Init  al  Configuration  process  in  the  Configuration  Module 


! 

Apparently,  the  VIDS-DMS  will  not  provide  any  capability  for  performing 
a  "warm  start."  That  is,  in  the  procedure  described  above,  the  Power  Up  Module 
loads  program  files  and  all  relatively  permanent  data  stored  in  the  system, 
such  as  threat  priorities,  aging  parameters,  and  vehicle  characteristics. 
However,  there  is  no  indication  in  the  draft  Procurement  Specification  that 
ephemeral  data  such  as  sensor  cross- correlations,  threat  locations,  current 
peripheral  status,  or  pending  crew  commands  can  be  saved  during  system  shut¬ 
down  procedures. 

And  yet,  one  can  imagine  situations  in  which  a  vehicle  crew  might  want  to 
preserve  these  data  for  a  short  period  while  the  system  is  temporarily  inopera¬ 
tive.  For  example,  during  a  lull  in  the  battle,  the  crew  might  be  relatively 
secure  from  danger  even  though  enemy  forces  are  within  range  of  at  least 
some  VIDS-DMS  sensors.  After  assessing  the  situation,  the  vehicle  commander 
might  accept  a  relatively  low  risk  in  order  to  shut  down  the  vehicle  and 
perform  an  urgent  but  quickly-accomplished  repair.  Such  repair  might  involve 
the  VIDS-DMS  or  some  other  vehicle  system  which  requires  complete  removal  of 
vehicle  power.  Upon  restoring  power  in  this  situation,  the  crew  very  well 
might  want  the  system  to  pick  up  precisely  where  it  left  off,  with  all 
ephemeral  data  intact  and  available  for  subsequent  system  operations. 

Recommendations 

1.  Provide  information  in  the  Initial  Configuration  Process 

message  to  notify  the  crew  of  the  status  of  system  peripherals . 

This  message  should  be  brief  (e.g.,  "READY.  NO  EQUIPMENT 
PROBLEMS "  or  "READY.  OPTICAL  SENSOR  INOP.").  (NOTE:  Examples 
such  as  these  are  not  intended  to  be  recommended  specifica¬ 
tions;  they  merely  exemplify  the  types  of  transactions  being 
discussed.)  A  graphic  presentation  could  be  used  (e.g.,  an 
outline  of  the  vehicle  with  green  spots  at  the  locations  of 
operating  peripherals  and  red  at  the  locations  of  inoperative 
peripherals) ;  however,  a  simple  alphanumeric  message  would 
probably  be  understood  more  quickly.  Guidelines  relevant  to 
this  issue  are  presented  in  the  following  sections  of  the 
Prototype  Handbook: 

2.1  Alphanumeric  Displays 

2.3  Selective  Highlighting 


6.2  Standard  Terms 


2.  Explore  the  necessity  for  a  "warm  start"  capability.  If  the 
capability  is  justified,  then  a  power  shut  down  procedure 
will  be  required  that  gives  the  crew  the  option  to  discard 
ephemeral  data  (for  a  later  cold  start)  or  to  save  it  (for 
a  later  warm  start)  before  power  is  actually  removed.  When 
the  "ON/OFF"  switch  is  turned  to  the  "OFF"  position,  a 
simple  query  should  be  addressed  to  the  crew  regarding  their 
wish  to  discard  or  preserve  the  ephemera)  data.  Relevant 
guidelines  will  be  found  in  the  following  sections  of  the 
Prototype  Handbook; 

1.1  Alphanumeric  Control  Methods 

2.1  Alphanumeric  Displays 

6 . 2  Standard  Terms 
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Prioritization  Hodul e 


Description 

The  Prioritization  Module,  shown  schematically  in  Figure  4,  is  respon¬ 
sible  for  prioritizing  and  scheduling  the  V1DS-DMS  main  processing  modules . 
This  will  include  the  Configuration,  Operational  Test,  Fault  Handling,  Input/ 
Output,  Control  Panel,  Threat  Resolution,  and  Reaction  Management  Modules. 

The  Prioritization  Module  responds  whenever  any  process  is  either  completed 
or  suspended.  The  module  directly  interfaces  with  the  Configuration,  Fault 
Handling,  and  Control  Panel  Modules  through  the  Process  Request  List.  The 
Threat  Resolution  Module  is  interfaced  through  the  Prioritized  Threat  List 
and  the  Reaction  Management  Module  through  the  Reaction  Data  File.  Files 
that  support  the  Prioritization  Module  include  Peripheral  Status  and  Vehicle 
Data  Files.  Both  these  files  are  updated  by  the  Configuration,  Operational 
Test,  and  Fault  Handling  Modules.  The  Prioritization  Module  also  interfaces 
the  Executive  through  the  Process  Schedule  and  is  real-time  critical.  The 
Prioritization  Module  performs  the  prioritization,  scheduling,  and  configura¬ 
tion  control  functions  at  the  highest  level  of  responsibility  not  performed 
by  the  operating  system.  The  Prioritization  Module  is  additionally  supported 
by  the  Prioritized  Threat  List,  Process  Prioritization  Tables,  Process 
Request  List,  Reaction  Data  Files.  (NOTE:  All  processes/modules  output  to 
the  Process  Request  List  for  use  by  the  Prioritization  Module  and,  ultimately. 
Process  Scheduling.) 


Soldier-Machine  Interface  Implications 

The  actions  of  the  Prioritization  Module  are  transparent  to  the  crew. 
While  a  process  initiated  by  the  prioritization  Module  may  eventually  inter¬ 
face  the  crew,  the  Prioritization  Module  itself  does  not.  The  Prioritization 
Module  in  and  of  itself  does  not  affect  the  SMI. 


Recommendations 


As  the  Prioritization  Module  does  not  directly  impact  the  SMI,  no  inter¬ 
face  recommendations  are  applicable. 


14 


Start 


Previous^ 

Process 

Coaipleted/ 

^uspended^ 


Process 

Schedule 


Peripheral j 
Status  I 
File  ' 


Process 

Request 

List 


Vehicle 

Data 

File 


Process 

Prioriti¬ 

zation 

Tables 


Reaction 

Data 

File 


Prioritized^ 
Threat  I 
List  1 


Executive 


Prioritization 

Nodule 


•  Dashed  line  used  for  plctoral  clarity  only. 
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Configuration  Module 

The  Configuration  Module  is  responsible  for  the  configuration  of  the  DMS. 
Its  overall  effect  is  the  ordering  and  reordering  of  software  processing  in 
response  to  a  peripheral  failure,  a  peripheral  fault,  or  a  change  in  the 
tactical  situation.  Four  processes  constitute  the  Configuration  Module:  the 
Initial  Configuration  Process,  the  Failure  Recon figurati on  Process,  the  Fault 
Reconfiguration  Process,  and  the  Tactical  Reconfiguration  Process.  (NOTE: 

The  Initial  Configuration  Process  was  discussed  previously,  in  conjunction 
with  the  Power  Up  Module.) 

FAILURE  RECONFIGURATION  PROCESS 


Description 


The  information  flow  and  sequence  for  the  Failure  Reconfiguration  Process 
are  illustrated  in  Figure  5.  The  essential  purpose  of  the  process  is  to 
reconfigure  system  tables,  parameters  and  program  modules  in  response  to  a 
peripheral  or  bus  failure.  The  Failure  Reconfiguration  Process  is  requested 
by  the  Fault  Handling  Module  after  a  hardware  interrupt.  The  process  is 
supported  by  the  Fault  Handling  Module,  the  Peripheral  Status  File,  the 
Vehicle  Data  File  and  the  Failure  Reconfiguration  Selection  Tables.  Upon 
process  completion,  the  Failure  Reconfiguration  Process  updates  the  Configu¬ 
ration  Status  File  to  incorporate  the  new  configuration,  and  interfaces 
directly  with  the  Input/Output  Module  through  the  updated  Control  Panel  Output 
File.  The  Failure  Reconfiguration  Process  works  in  coordination  with  the 
Initial  Configuration  Process ,  Fault  Recovery  Process ,  and  the  Tactical 
Reconfiguration  Process. 


Soldier-Machine  Interface  Implications 


The  Failure  Reconfiguration  Process's  direct  interface  with  the  Input/ 
Output  Module  through  the  Control  Panel  Output  File  suggests  that  the  pro¬ 
cess  generates  a  message  to  the  crew.  However,  the  Draft  Specification 
does  not  specify  the  purpose  or  content  of  any  such  message.  The  document 
does  state  that  the  Status  Fault  Process  and/or  the  Data  Content  Fault 
Process  will  generate  the  appropriate  message  whenever  a  failed  peripheral 


must  be  physically  removed.  Therefore,  one  may  infer  that  the  message  gener¬ 
ated  by  the  Failure  Reconfiguration  Process  serves  sane  other  function  than 
peripheral  removal.  That  function  appears  to  be  to  notify  the  crew  that 
reconfiguration  has  taken  place.  If  so,  the  question  arises  as  to  the 
importance  of  this  notice  as  comp  aired  to  other  information  (for  exaunple, 
warnings  of  imminent  threats).  Also,  the  method  of  presenting  the  message 
becomes  an  issue. 

The  Draft  Specification  appears  to  allow  no  capability  for  the  crew  to 
overrule  the  Failure  Reconfiguration  Process.  Presumably,  the  Process 
reconfigures  the  system  based  upon  information  stored  in  the  Peripheral 
Status  File  by  other  processes.  The  cause  of  a  failure  notification  in  that 
file  evidently  results  from  a  comparison  of  peripheral  status  against  same 
minimum  acceptable  value.  However,  one  can  conceive  of  situations  in  which 
that  value  is  lower  for  the  crew  than  for  the  system.  That  is,  under  the 
exigencies  of  combat,  the  crew  might  prefer  the  assistance  of  even  a  seriously 
degraded  (but  not  completely  failed)  peripheral,  given  the  alternative  of  no 
peripheral  at  all.  Probably,  disucssion  with  subject  matter  experts  would 
resolve  this  issue. 

Recommendations 

1.  The  crew  should  be  notified  immediately  of  any  reconfiguration 
unless  more  pressing  information  (e.g.,  a  threat  warning)  is 
available.  This  notification  should  be  presented  as  an  alpha¬ 
numeric  text  message  indicating  the  identification  of  the 
peripheral  that  has  been  configured  out  of  the  system  and  the 
reason  for  the  reconfiguration  (e.g.,  the  peripheral  is  inoper¬ 
ative,  voltage  has  dropped  below  its  minimum  acceptable  value). 

The  peripheral  identification  should  be  highlighted  to  permit 
easy  detection  by  the  crew  of  this  critical  piece  of  informa¬ 
tion.  The  notification  should  be  maintained  on  the  display 
device  until  acknowledged  by  the  crew. 

Sections  of  the  Prototype  Handbook  relating  to  display  issues 
in  the  Failure  Reconfiguration  Process  are: 

2.1  Alphanumeric  Displays 
2.3  Selective  Highlighting 

3.2  Unburdening  of  Input 
6.1  Symbols  and  Symbol  Sets 
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6.2  Standard  Terms 


6.3  Abbreviations 

7 . 1  Error  Feedback 

7.2  Error  Correction  and  Recovery 

2.  Additionally,  if  TACOM  determines  that  the  crew  requires  the 
capability  to  overrule  this  process,  then  crew  instructions 
to  the  process  should  be  entered  using  simple  alphanumeric 
control  methods.  Relevant  guidance  is  provided  by  the 
Prototype  Handbook  in: 

1.1  Alphanumeric  Control  Methods 

3.1  Information  on  Legal  Entries 

Example  of  Handbook  Usage.  For  an  example  of  the  use  of  guide¬ 
lines,  consider  the  message  that  reconfiguration  has  been  accom¬ 
plished.  The  crew  needs  to  know  which  peripheral  has  failed  and 
caused  the  failure  reconfiguration,  because  this  information  may 
well  influence  decisions  for  the  remainder  of  the  mission. 
Therefore,  as  noted  above,  this  critical  item  of  information 
should  be  highlighted  to  help  the  crew  locate  the  information 
quickly.  Section  2.3  of  the  Prototype  Handbook  describes  and 
illustrates  various  applications  for  selective  highlighting,  and 
various  highlighting  methods. 

One  application  described  in  this  section  is  "to  call  attention 
to  high  priority  codes  or  messages"  (such  as  a  failed  peripheral) 
The  Handbook  provides  the  following  example  of  this  application : 

EXAMPLE:  In  an  artillery  data  system,  the  user/operator 
must  be  certain  that  the  target  coordinates  for  a  fire 
mission  do  not  mean  that  friendly  fire  will  impact  on 
friendly  forces.  The  data  indicating  these  coordinates 
is  therefore  highlighted  when  it  is  displayed  (page  2.3-3). 

In  describing  methods  for  highlighting,  the  Handbook  mentions 
brightness  control  as  one  such  method: 


Table  1  (reproduced  from  Table  2.3-3  in  the  Handbook,  page  2.3-13) 
presents  recommendations  concerning  preferred  highlighting  methods 
for  different  applications.  Ihe  table  shews  that  for  high  priority 
messages  or  codes,  four  methods  are  recommended:  brightness 
control,  character  size  control,  color  control,  and  boxing.  For 
purposes  of  standardizing  soldier-machine  interactions  in  Army 
battlefield  automated  systems,  the  table  recommends  using  bright¬ 
ness  control,  and  that  method  is  therefore  recommended  for  the 
VIDS-DMS. 


Table  1.  Method  of  Selective  Highlighting  by 
Reason  for  Using  Highlighting 


APPLICATION 


1  •  RECOWNDED 

2  -  ACCEPTABLE 

3  -  WORKABLE  BUT 

SUB OPTIMAL 

4  .  not  recommended  or 

NOT  APPLICABLE 
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FAULT  RECONFIGURATION  PROCESS 


Description 

The  Fault  Reconfiguration  Process,  shown  schematically  in  Figure  6,  is 
responsible  for  the  reconfiguration  of  the  DMS  in  the  event  of  a  fault 
condition.  This  differs  from  the  Tactical  Reconfiguration  Process  which 
reconfigures  from  a  change  in  a  tactical  situation.  The  Fault  Reconfiguration 
Process  is  called  by  the  Fault  Handling  Module  through  the  Peripheral  Status 
File  and  Vehicle  Data  File  interfaces.  The  Vehicle  Data  File  and  Peripheral 
Data  File  support  the  Fault  Reconfiguration  Process  as  do  the  Fault  Reconfigu¬ 
ration  Selection  Tables  and  the  Process  Schedule.  The  Fault  Reconfiguration 
Process  interfaces  the  Executive  through  the  Process  Schedule  and  the  Input/ 
Output  Module  through  the  Control  Panel  Output  File.  The  process  also  updates 
the  Configuration  Status  File  for  use  by  other  system  modules.  This  process 
is  real-time  critical  and  generates  a  message  to  the  Control  Panel  Output 
File. 

Soldier-Machine  Interface  Implications 

The  Fault  Reconfiguration  Process  is  anticipated  to  generate  a  status 
or  warning  message  to  the  crew.  The  message  may  be  aural,  or  involve  the 
display,  or  both.  The  crew  may  be  expected  to  acknowledge  the  message 
through  a  simple  mechanism  such  as  a  push-button.  The  details  of  the  SMI 
implication  are  the  same  as  those  expressed  for  the  Failure  Reconfiguration 
Process  and  are  not  duplicated  here. 

Recommendations 

Recommendations  1  and  2  of  the  Failure  Reconfiguration  Process  apply. 
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Schematic  of  System  Functions  Involving  the  Fault  Reconfiguration 
Process  in  the  Configuration  Module 


TACTICAL  RECONFIGURATION  PROCESS 


Description 

The  Tactical  Reconfiguration  Process,  shown  schematically  in  Figure  7, 
performs  the  function  of  reconfiguring  tactical  processing  in  response  to  a 
change  in  the  vehicle's  tactical  situation.  The  Tactical  Reconfiguration 
Process  is  requested  by  the  Prioritization  Module  or  by  crew  input.  The 
process  is  supported  by  the  Tactical  Reconfiguration  Selection  Tables  and 
updates,  as  an  output,  the  Configuration  Status  File  and  the  Peripheral 
Command  File.  The  Peripheral  Status  File  and  the  Vehicle  Data  File  are 
also  updated  and  used  by  the  Prioritization  and  Threat  Resolution  Modules. 

The  updated  Configuration  Status  File  is  available  for  system-wide  modules. 

The  Process  Schedule  is  also  modified  by  the  Tactical  Reconfiguration  Process 
for  changes  in  the  processing  sequence.  The  updated  Peripheral  Command  File 
is  used  for  changes  in  the  Self-Test  and  Status  Check  Processes. 

Soldier-Machine  Interface  Inpli cations 

Hie  draft  Procurement  Specification  does  not  show  any  output  to  the 
Control  Panel  Output  File  from  the  Tactical  Reconfiguration  Process.  However, 
if  tactical  reconfiguration  results  in  any  pronounced  change  in  the  system's 
configuration,  then  a  message  to  the  crew  announcing  this  change  should  be 
provided.  Such  a  message  would  be  important  to  confirm  a  reconfiguration 
initiated  by  crew  input;  it  will  be  particularly  important;  when  a  tactical 
reconfiguration  has  been  initiated  automatically  by  the  system. 

In  the  case  of  crew  input  initiating  a  tactical  reconfiguration,  that 
input  presumably  would  be  entered  as  a  crew  response  to  a  perceived  change  in 
the  tactical  situation  during  combat  operations .  The  draft  Procurement 
Specification  does  not  describe  the  extent  of  crew  control  when  they  invoke 
the  Tactical  Reconfiguration  Process.  For  example,  would  the  crew  input 
consist  merely  of  a  command  to  execute  the  process,  at  which  command  the 
system  would  take  over  and  reconfigure  without  further  crew  participation? 

Or  would  the  crew  play  a  more  active  role  in  the  process,  perhaps  having  the 
capability  to  specify  desired  reconfiguration  parameters?  In  the  latter  case, 
then  the  method  for  presenting  these  parameters  as  input  options  must  be  clear 
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Figure  7.  Schematic  of  System  Functions  Involving  the  Tactical  Reconfiguration 
Process  in  the  Configuration  Module 
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and  unequivocable;  the  demand  for  crew  consideration  and  decision  making  must 
be  minimized.  Similarly,  the  method  for  entering  parameter  selections  must 
be  simple  and  rapid,  with  minimal  demand  for  physical  skills.  Because  tac¬ 
tical  reconfiguration  usually  will  be  performed  under  battlefield  conditions 
where  seconds  literally  may  be  crucial  to  vehicle  and  crew  survival,  consider 
ations  of  speed  and  simplicity  must  be  paramount  in  the  design  of  the  crew- 
system  interaction. 

Recommendations 

The  following  recommendations  assume  that  crew  input  to  the  Tactical 
Reconfiguration  Process  consists  of  something  more  than  a  simple  initiating 
command . 

1.  Provide  a  method  to  make  reconfiguration  options  available 
to  the  crew  on  the  alphanumeric  display.  Give  the  crew 
the  capability  to  enter  peripheral  device  selections  by 
number.  Do  not  require  reference  to  offline  documents  or 
other  crew  members  for  this  procedure;  provide  all  required 
information  through  the  system.  Guidelines  relevant  to  this 
recommendation  include  the  following  sections  in  the 
Prototype  Handbook; 

1.1  Alphanumeric  Control  Methods 

2.1  Alphanumeric  Displays 

2 . 2  Graphics  Displays 

3.1  Information  on  Legal  Entries 

3.2  Unburdening  of  Input 

6.1  Symbols  and  Symbol  Sets 

6 . 2  Standard  Terms 

6.3  Abbreviations  and  Codes 


7.1  Error  Feedback 

7.2  Error  Correction  and  Recovery 

2.  The  selection  of  peripheral  devices  must  be  accomplished  by 
no  more  than  one  action  (e.g.,  keystroke)  per  device. 

3.  The  inadvertant  selection  of  a  failed  or  unavailable 
peripheral  must  invoke  a  system-generated  message  to  this 
effect.  This  message  should  require  a  positive  corrective 
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action  by  the  crew,  to  avoid  the  possibility  they  will  conduct 
subsequent  operations  based  on  an  erroneous  belief  that  a 
failed  or  otherwise  unavailable  peripheral  is  operating 
normally. 

The  following  recommendation  deals  with  the  need  for  an  output  message 
to  the  crew  following  tactical  reconfiguration,  and  is  not  related  to  the 
nature  of  crew-system  interaction  in  initiating  the  process. 

4.  Provide  a  message  to  the  crew  showing  the  new  configuration 
after  tactical  reconfiguration  has  been  accomplished.  Guide¬ 
lines  appropriate  to  this  recommendation  are  suggested  under 
"Recommendations"  for  the  Failure  Reconfiguration  Process. 
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Operational  Test  Module 


The  Operational  Test  Module  provides  the  system  with  a  built-in  test 
capability.  It  is  comprised  of  the  Status  Check  Process  and  the  Self-Test 
Process . 

STATUS  CHECK  PROCESS 
Description 

The  Status  Check  Process,  shown  schematiclaly  in  Figure  8,  performs 
routine  monitoring  of  the  operational  status  of  all  peripheral  components. 

If  a  peripheral  failure  is  detected,  the  Input/Output  Module  invokes  the 
Status  Check  Process  through  the  Status  Input  Buffer.  Using  data  from  the 
Configuration  Status  File,  the  Status  Check  Process  checks  the  status  of 
peripherals  through  the  Input/Output  Module  (via  the  Peripheral  Command  File) 
and  modifies  the  Peripheral  Status  File  and  the  Vehicle  Data  File  for  use  by 
the  Configuration  Module,  the  Prioritization  Module,  and  the  Threat  Resolution 
Module.  It  also  outputs  the  results  of  the  status  checks  to  the  Process 
Request  List  for  use  by  the  Prioritization  Module.  The  ptciC&ss  monitors  normal 
operation;  it  does  not  perform  fault  diagnosis  or  test  peripheral  component 
operation.  The  effect  of  the  Status  Check  Process  is  merely  to  announce  a 
peripheral  failure,  calling  to  the  attention  of  tne  Prioritization  Module 
the  need  to  schedule  failure  diagnosis/correction  by  other  processes. 

Soldier-Machine  Interface  Implications 

The  Status  Check  Process  itself  provides  no  message  to  the  crew  regarding 
the  status  of  peripheral  component  operation  nor  does  it  directly  occasion 
any  soldier-machine  interaction. 

Recommendations 

Because  the  Status  Check  Process  does  not  interact  with  the  crew,  no 
recommendations  are  required. 
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Figure  8.  Schematic  of  System  Functions  Involving  the  Status  Check  Process 
in  the  Operational  Test  Module 
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SELF-TEST  PROCESS 


Description 


The  Self-Test  Process,  illustrated  schematically  in  Figure  9,  handles 
unscheduled  or  infrequently  scheduled  system  diagnostics.  Interpretation  of 
the  draft  Procurement  Specification  suggests  that  the  Self-Test  Process  does 
not  itself  perform  these  diagnostic  functions.  Instead,  it  calls  the  process 
or  processes  which  do  the  actual  diagnostic  testing  on  the  questionable 
peripheral . 


The  Self-Test  Process  is  requested  by  the  Fault  Handling  Module,  when 
more  thorough  testing  than  that  performed  by  the  Status  Check  Process  is 
desired.  The  Fault  Handling  Module  may  be  called  in  response  to  automatic 
system  procedures  or  in  response  to  a  crew  input;  in  either  case  it  calls  the 
Self-Test  Process  to  handle  the  more  extensive  testing.  The  process  uses 
data  from  the  Configuration  Status  file  and  from  the  Test  Selection  Tables. 
Based  upon  fault  indicator  parameters  in  the  Configuration  Status  File,  the 
Test  Selection  Tables  point  to  the  particular  self-test  process  (procedure) 
that  is  appropriate  to  the  specific  diagnostic  situation. 

The  Self-Test  Process  generates  commands  to  peripherals,  which  it  stores 
in  the  Peripheral  Command  File.  The  Input/Output  Module  interprets  these 
commands  and  modifies  the  Peripheral  Status  File  and  the  Vehicle  Data  File 
for  subsequent  use  by  the  Configuration  Module,  the  Prioritization  Module, 
and  the  Threat  Resolution  Module. 


Soldier-Machine  Interface  Implications 


As  noted  above,  the  Self-Test  Process  is  invoked  only  when  more  thorough 
testing  is  required  than  is  normally  performed  by  the  other  diagnostic  processes 
that  are  called  automatically  in  response  to  system  interrupts.  Presumably 
then,  the  crew  will  call  for  this  process  only  when  they  have  reason  to  suspect 
that  one  of  the  system's  peripherals  is  not  operating  normally.  Such  suspicions 
might  be  aroused  either  by  system  reports  of  other  test  results,  or  by  direct 
crew  observations  of  the  peripheral ' s  performance .  In  either  case ,  the  Self- 
Test  Process  will  not  be  a  routine,  frequently  used  procedure. 
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Figure  9.  Schematic  of  System  Functions  Involving  the  Self-Test  Process  in 
the  Operational  Test  Module 
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The  crew  naturally  will  have  received  instruction  and  practice  in  its 
use  as  part  of  their  training.  However,  precisely  because  they  will  use  it 
relatively  rarely  during  combat  operations  and/or  exercises,  they  cannot  be 
expected  to  learn  it  as  thoroughly  as  other  modules  and  processes .  This 
fact  must  be  an  important  consideration  during  the  design  of  the  SMI. 

In  addition,  the  draft  Procurement  Specification  does  not  describe  any 
kind  of  acknowledgement  of  a  crew  request  for  the  Self-Test  Process.  Neither 
does  it  describe  a  message  confirming  that  the  process  has  been  executed,  or 
any  kind  of  output  to  inform  the  crew  of  the  system's  conclusions  regarding 
test  results.  The  lack  of  acknowledgement,  confirmation,  and  test  conclu¬ 
sions  would  leave  the  crew  in  a  state  of  pronounced  uncertainty  as  regards 
system  status,  possibly  at  a  time  when  critical  decisions  might  hinge  on  such 
knowledge . 


Recommendations 


1.  Provide  an  acknowledgement  on  the  crew  display  whenever  the 
crew  calls  for  the  Self-Test  Process.  This  acknowledgement 
could  be  quite  simple,  for  example  "(name  of  peripheral)  NOT 
BEING  TESTED." 

2.  Whether  invoked  automaticlaly  or  by  crew  input,  provide  a 
message  clearly  stating  the  outcome  of  the  Self-Test  Process, 
informing  the  crew  of  any  changes  in  peripheral  status .  If 
the  Self-Test  Process  was  called  automatically,  then  provide 
this  message  only  by  exception,  when  status  has  actually 
changed.  If  the  process  was  called  by  crew  input,  provide  the 
message  even  if  peripheral  status  has  not  changed. 

3.  Because  of  the  relative  infrequency  of  crew-system  interaction 
relating  to  this  process,  exercise  particular  care  in  design¬ 
ing  messages  to  the  crew  and  structuring  crew  inputs.  Provide 
ample  explanation  and  instruction  on  performing  the  interac- 
tion,  but  avoid  redundancy,  repetition,  and  extraneous  infor¬ 
mation.  A  naive  operator  should  be  able  to  complete  the 
necessary  transactions  quickly,  accurately,  and  without 
reference  to  off-line  sources. 

Guidelines  relevant  to  support  of  interface  issues  of  the  Self-Test 
Process  include: 

1.1  Alphanumeric  Control  Methods 
1 . 3  HELPS 
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2.1  Alphanumeric  Displays 
2.3  Selective  Highlighting 

3.1  Information  on  Legal  Entries 

3.2  Unburdening  of  Input 

6.1  Symbols  and  Symbol  Sets 

6.2  Standard  Terms 

7.1  Error  Feedback 

7.2  Error  Correction  and  Recovery 


to 


The  Fault  Handling  Module  responds  to  fault  conditions  detected  through 
normal  operation  or  self  testing.  It  consists  of  three  processes  with  each 
process  responding  to  a  unique  fault  type:  the  Bus  Hardware  Fault  Process, 
the  Status  Fault  Process,  and  the  Data  Content  Fault  Process. 

BUS  HARDWARE  FAULT  PROCESS 


Description 

The  Bus  Hardware  Fault  Process  is  illustrated  in  Figure  10.  The  Bus 
Hardware  Fault  Process  is  called  in  response  to  a  detected  fault.  The 
detected  fault  can  be  in  the  bus  hardware ,  peripheral  processor ,  or  communi¬ 
cation  bus.  The  Fault  Process  is  supported  by  the  Configuration  Status  File 
and  the  Hard  Fault  Test  Tables.  The  Bus  Hardware  Fault  Process  updates  the 
Peripheral  Status  File  and  the  Vehicle  Status  File.  These  files  are  used  by 
the  Configuration  Prioritization  and  Threat  Resolution  Modules.  The  process 
also  interfaces  the  Prioritization  Module  through  the  Process  Request  List. 
This  process  is  considered  real-time  critical.  The  Bus  Hardware  Fault 
Process  works  in  concert  with  the  Status  Fault  Process  and  the  Data  Content 
Fault  Process,  both  part  of  the  Fault  Handling  Module. 

Soldier-Machine  Interface  Implications 

This  process  does  not  remove,  shut  down,  or  reconfigure  devices,  or 
initiate  displays  as  part  of  its  operation.  Fault  information  appears  to 
be  used  to  update  files  for  further  processing  by  other  modules.  The 
process,  therefore,  appears  to  be  transparent  to  the  vehicle  crew,  although 
another  module  may  use  the  fault  information  in  such  a  manner  as  to  affect 
the  current  configuration  to  necessitate  status  information  or  reaction 
by  the  crew. 

Recommendations 

As  the  Bus  Hardware  Fault  Process  does  not  appear  to  affect  vehicle 
or  crew  performance  as  a  direct  result  of  its  function,  SMI  guidelines  are 
not  indicated. 
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Lgure  10.  Schematic  of  System  Functions  Involving  the  Bus  Hardware  Fault 
Process  in  the  Fault  Handling  Module 
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STATUS  FAULT  PROCESS 


Description 

The  Status  Fault  Process,  illustrated  in  Figure  11,  performs  fault 
handling  on  status  errors  resulting  from  status  checks  or  other  poll  commands. 
The  process  tests  the  fault  for  recurrence  and,  based  upon  the  results, 
performs  one  of  three  actions.  Frist,  if  the  fault  is  not  detected,  it  will 
track  the  device  to  assure  fault-free  operation.  Second,  if  the  fault  is 
detected,  the  device  will  be  reset  and  tested  again.  Third,  continued  fault 
indication  will  cause  a  message  to  the  crew  telling  them  to  remove  the  periph¬ 
eral.  The  process  uses  the  Configuration  Status  File  and  Status  Fault  Test 
Tables,  updates  the  Peripheral  Status  File  and  the  Vehicle  Data  File.  The 
updated  files  are  used  by  the  Configuration,  Prioritization  and  Threat 
Resolution  Modules.  The  Status  Fault  Process  also  interfaces  the  Prioritiza¬ 
tion  Module  through  the  Process  Request  List.  The  crew  message  is  initiated 
through  the  Control  Panel  Output  File.  The  Status  Fault  Process  works  in 
concert  with  the  Bus  Hardware  Fault  Process,  and  the  Data  Content  Fault  Process 

Soldier-Machine  Interface  Implications 

The  only  interaction  between  the  crew  and  the  system  appears  to  be  the 
message  advising  the  crew  to  physically  remove  the  failed  peripheral  from  the 
system. 

Recommendations 

1.  Sections  of  the  prototype  Handbook  relating  to  the  interface 

design  supporting  the  Status  Fault  Process  are: 

1.1  Alphanumeric  Control  Methods 

2.1  Alphanumeric  Displays 

2.2  Graphics  Displays 

6.1  Symbols  and  Symbol  Sets 

6.2  Standard  Sets 

6.3  Abbreviations  and  Codes 

7.1  Error  Feedback 

7.2  Error  Correction  and  Recovery 
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Figure  11.  Schematic  of  System  Functions  Involving  the  Status  Fault  Process 
in  the  Fault  Handling  Module 
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Example  of  Handbook  Usage.  As  an  example,  the  Prototype  Handbook 1 s  Section  2 
Display  Techniques,  presents  guidelines  on  techniques  to  present  information 
to  the  crew. 


Table  2,  which  is  reproduced  from  the  Prototype  Handbook, 
illustrates  applications  and  display  techniques.  The  message  to 
remove  the  peripheral  is  one  type  of  "Fixed  or  Free  Text  Data." 


Table  2.  Display  Techniques  by  Application 


APPLICATION  | 

DISPLAY 

TECHNIQUE 

Fixed  or 

Tree  Teat 

Data 

Statistical 

Report 
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Alphanumeric 

1 

1 

3 

3 

1 

i 

Graphic 

3 

2 

1 

1 

2 
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KEY: 

1  ■  APPROPRIATE 

2  -  ACCEPTABLE 

3  -  INAPPROPRIATE 


To  further  continue  the  example,  methods  for  implementing 
alphanumeric  displays  are  also  discussed  in  the  Prototype 
Handbook .  A  summary  of  this  discussion  is  presented  as 
Table  3,  which  is  reproduced  from  the  Prototype  Handbook. 

Table  3.  Method  of  Alphanumeric  Display  by  Application 


KEY: 

APPLICATION 

1  -  RECOMMENDED 

2  -  ACCEPTABLE 

3  -  WORKABLE  BUT  SUBOPTIMAL 

4  -  NOT  RECOMMENDED  OR  NOT 

APPLICABLE 

LAYOUTS  FOR  DATA 

ENTRY 

DATA  DISPLAY  FOR  IN¬ 
FORMATION  OR  ACTION 

DISPLAY  OF  PERFOR¬ 
MANCE  OPTIONS 

PRESENTATION  OF 

HELPS 

PRESENTATION  OF  ERROR 
INFORMATION 

METHOD 

FIXED  ALPHANUMERIC  DISPLAYS 

: 

LISTS 

4 

1* 

1* 

* 

3 

PRESTRUCTURED  FORMATS 

1 

1 

2 

2 

2 

HELPS 

4 

1 

2 

1 

4 

ERROR  MESSAGES 

4 

2 

3 

4 

1 

VARIABLE  ALPHANUMERIC  DISPLAYS 

x’x'x'x-x*! 

FREE  TEXT  REPORT 

2 

2 

1 

* 

4 

SHOEBOX  (PERSONNEL)  FILES 

2 

2 

1 

2 

♦Recommended  as  1st  choice  for  standardization  purposes. 


The  application  most  appropriate  to  the  message  to  remove  a  periph¬ 
eral  is  the  "Data  Display  for  Information  or  Action."  The  recom¬ 
mended  method  for  this  application  is  "Lists."  Thus,  a  one-line 
alphanumeric  list  would  be  the  best  method  for  presenting  the 
message. 

Recommendations  2,  3,  and  4  below  were  derived  from  the  Prototype 
Handbook . 

2.  Provide  crew  members  with  the  capability  to  call  a  retest  of 
the  peripheral  indicated. 

3.  Provide  crew  members  the  ability  to  retain  a  degraded  periph¬ 
eral  in  the  VIDS  if  they  feel  it  is  providing  some  useful 
information. 


4.  Require  crew  acknowledgement  of  system-generated  messages  if 
those  messages  require  crew  action. 


DATA  CONTENT  FAULT  PROCESS 


Description 

The  Data  Content  Fault  Process,  shown  schematically  in  Figure  12, 
responds  to  data  content  faults  and  is  requested  each  time  such  a  fault 
occurs.  This  process  initiates  the  Status  Check  or  Self-Test  Process  which, 
depending  on  test  results,  may  initiate  the  Status  Fault  Process.  The 
results  of  the  combined  processes  can  be  any  one  of  three  situations. 

First,  the  error  can  be  corrected.  Secondly,  the  suspect  device  can  be 
reset  and  retested,  or  thirdly,  a  message  cam  be  generated  to  the  crew  to 
remove  the  failed  peripheral. 

The  Data  Content  Fault  Process  updates  the  Peripheral  Status  File  for 
use  by  the  Configuration,  Prioritization  and  Threat  Resolution  Modules.  The 
Prioritization  Module  is  also  directly  interfaced  through  the  Process  Request 
List.  The  Data  Content  Fault  Process  is  supported  by  the  Configuration  Status 
File  and  the  Data  Content  Test  Tables.  The  process  works  in  concert  with 
the  Bus  Hardware  Fault  Process,  the  Status  Fault  Process,  the  Self-Test 
Process,  and  the  Status  Check  Process. 

Soldier  Machine  Interface  Implications 

This  procet  requires  essentially  the  same  crew  actions  and  reactions 
as  the  Status  Fault  Process  and  is  not,  therefore,  discussed  further  here. 

Recommendations 

See  those  provided  for  in  the  Status  Fault  Process. 
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Figure  12.  Schematic  of  System  Functions  Involving  the  Data  Content  Fault 
Process  in  the  Fault  Handling  Module 
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Input/Output  Module 


The  Input/Output  Module  carries  out  the  transfer  of  data  to  and  from 
peripherals  as  well  as  the  preliminary  sorting  of  data  into  data  and  status 
information.  The  Input /Output  Module  consists  of  the  Interrupt  Handler 
Process,  the  Bus  Data  Input  Process,  the  Bus  Data  Output  Process,  and  the 
Link  Monitor  Process.  (NOTE:  This  discussion  does  not  treat  the  Link 
Monitor  Process  since  its  function ,  that  of  providing  the  interface  between 
the  running  operational  system  in  the  vehicle  and  the  external  development 
operating  system,  is  actually  external  to  the  operating  system  with  which 
this  analysis  deals.) 
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INTERRUPT  HANDLER  PROCESS 
Description 

The  Interrupt  Handler  Process,  illustrated  in  Figure  13,  acknowledges, 
interrupts,  analyzes  the  cause,  and  determines  the  action  to  be  taken  to 
resolve  the  interrupt.  The  process  responds  to  a  hardware-generated  inter¬ 
rupt  and  provides  interrupt-specific  routines  to  resolve  the  interrupts. 

The  Hardware  Interrupt  System  supports  the  Interrupt  Handler  Process  and 
calls  the  process  when  a  device  signals  an  interrupt  to  the  CPU  or  operating 
system.  The  Interrupt  Handler  Process  outputs  the  Process  Request  List  which 
interfaces  the  Prioritization  Module.  The  Interrupt  Handler  Process  works 
in  conjunction  with  the  Bus  Data  Input,  and  Bus  Data  Output  Processes  of  the 
Input /Output  Module. 

Soldier-Machine  Interface  Implications 

The  Interrupt  Handler  is,  in  itself,  transparent  to  the  crew.  Any 
eventual  crew  action  is  covered  through  the  Fault  Handling  Module. 

Recommendations 

No  guidelines  for  interface  design  are  applicable  to  this  process. 
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BUS  DATA  INPUT  PROCESS 


Description 


The  Bus  Data  Input  Process,  shown  schematically  in  Figure  14,  receives 
peripheral  information  from  the  1553B  Bus  and  conditions  the  data  for  use 
by  the  operating  system  and  application  programs.  This  process  is  supported 
by  the  processes  and  status  data  received  from  the  Input  and  Output  Data 
Buffers.  The  Bus  Data  Input  Process  updates  the  Data  Input  Files,  Status 
Input  Files,  and  Process  Request  List.  Directly  interfacing  the  Bus  Data 
Input  Process  is  the  Prioritization  Module.  The  Bus  Data  Input  Process  works 
in  conjunction  with  the  Bus  Data  Output  Process  and  interrupt  Handler  of  the 
Input /Out put  Module. 

Soldier-Machine  Interface  Implications 
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BUS  DATA  OUTPUT  PROCESS 


Description 

The  Bus  Data  Output  Process,  illustrated  in  Figure  15,  receives  data 
from  application  programs  and  performs  the  processing  necessary  for  the 
system  to  send  data  to  the  peripherals  through  the  1553B  Bus.  The  Bus  Data 
Output  Process  is  supported  by  the  Control  Panel  Output  File,  the  Counter¬ 
measure  Activity  Files,  the  Peripheral  Command  File,  and  the  Tactical  Warning 
Display  File.  The  Bus  Data  Output  Process  updates  the  Input  Data  Buffers, 
Output  Data  Buffers,  and  the  Process  Request  List.  The  Bus  Data  Output 
Process  interfaces  with  the  Prioritization  Module  which  communicates  with  the 
Executive.  The  Bus  Data  Output  Process  works  in  conjunction  with  the  Bus 
Data  Input  Process  and  the  Interrupt  Handler  of  the  Input/Output  Module. 


CONTROL  PANEL  MODULE 


The  Control  Panel  Module  provides  the  software  for  processing  data  which 
are  input  to  the  system  by  vehicle  crew  members ;  it  is  responsible  for 
interpreting  and  carrying  out  crew  commands.  The  Control  Panel  Module 
consists  of  two  processes,  the  Control  Panel  Input  Process  and  the  Command 
Resolution  Process. 

CONTROL  PANEL  INPUT  PROCESS 

Description 

The  Control  Panel  Input  Process,  shown  schematically  in  Figure  16, 
receives  commands  from  the  crew  via  the  Control  Panel  and  schedules  the 
processes  necessary  to  carry  out  those  commands;  it  converts  raw  commands 
into  system  commands.  When  a  crew  command  is  entered,  the  Control  Panel 
Input  Process  is  invoked  by  the  Input/Output  Module  through  the  Data  Input 
Buffers.  Through  the  Crew  Command  File,  the  Control  Panel  Input  Process 
outputs  system  commands  to  the  Process  Request  List  for  use  by  the  Prioriti¬ 
zation  Module  and  Process  Scheduling.  The  Control  Panel  Input  Process 
requests  that  when  the  Prioritization  Module  addresses  the  commands— via  the 
Crew  Command  File — that  commands  not  requiring  a  reaction  be  handled  directly 
through  the  Command  Resolution  Process  and  that  commands  that  do  require  a 
reaction  first  be  handled  through  the  Reaction  Decision  Process  and  then  by 
the  Reaction  Management  Module. 

Soldier-Machine  Interface  Implications 

The  Control  Panel  Input  Module  handles  only  crew  responses  and  commands 
to  the  system;  it  does  not  appear  to  have  any  role  in  system  outputs  to  the 
crew.  Moreover,  for  reasons  outlined  earlier  under  "General  Findings,"  crew 
inputs  typically  will  be  terse,  often  consisting  of  a  single  character  or 
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Recommendations 


1.  There  appears  to  be  no  requirement  for  the  type  of  alphanu¬ 
meric  keyboard  found  on  typewriters  (the  so-called  "QWERTY" 
keyboard) .  Use  function  keys  for  standard  crew  inputs,  such 
as  acknowledging  system  outputs;  these  might  be  incorporated 
into  a  touch-sensitive  panel.  The  display  device  itself 
should  have  a  touch-sensitive  surface  to  permit  the  crew  to 
select  options  merely  by  touching  them.  A  high  level  of 
error  detection,  feedback,  and  correction  capability  will  be 
required  to  permit  rapid  error  diagnosis  and  correction. 
Guidelines  appropriate  to  these  issues  will  be  found  in 
sections : 

1.1  Alphanumeric  Control  Methods 

1.2  Graphics  Control  Methods 

1.3  HELPS 

3.1  Information  on  Legal  Entries 

3.3  Interrupts  and  Work  Recovery 

5.1  Query  Methods 

7 . 1  Error  Feedback 

7.2  Error  Correction  and  Recovery 


COMMAND  RESOLUTION  PROCESS 


Description 

The  Command  Resolution  Process,  shown  schematically  in  Figure  17,  pro¬ 
cesses  all  crew  conn  an ds  with  the  exception  of  countermeasure  initiator 
commands .  This  process  is  requested  by  the  Control  Panel  Input  Process  with 
the  Crew  Command  File  as  its  interface.  It  uses  data  in  the  Crew  Command 
File  and  the  Crew  Command  Table;  it  distinguishes  status  inputs  from  data 
requested  data  on  the  Control  Panel.  To  achieve  this,  the  Bus  Data  Output 
Process  of  the  Input/Output  Module  is  invoked  via  the  Control  Panel  Output 
File  and  the  message  is  displayed  to  the  crew  via  the  Output  Data  Buffers. 

For  command  inputs,  the  Command  Resolution  Process  schedules  the  command  using 
data  from  the  Process  Request  List  and  the  Configuration  status  File. 

Soldier-Machine  Interface  Implications 

The  Command  Resolution  Process  does  not  receive  crew  inputs  directly, 
and  thus  is  not  involved  in  the  input  process.  It  does,  however,  generate 
outputs  to  the  crew,  providing  status  information  on  demand.  The  need  for 
easily  understood  information  is  thus  as  great  here  as  in  other  modules  and 
processes . 

Recommendations 

1.  In  designing  status  displays  to  be  provided  in  response  to 

crew  demands,  ensure  that  such  displays  respond  to  the  specific 
demand.  Do  not,  for  example,  generate  a  single,  all-purpose 
message  showing  the  status  of  all  peripherals.  Such  a  message 
might  be  appropriate  for  the  Initial  Configuration  Process,  but 
not  here.  If  the  crew  wishes  to  see  the  status  of  the  optical 
sensor,  for  example,  presenting  a  general  status  message  would 
force  them  to  waste  time  scanning  through  the  message  to 
locate  the  optical  sensor.  Guidelines  relating  to  status 
messages  are  contained  in  the  following  sections  of  the 
Prototype  Handbook  •. 

2.1  Alphanumeric  Displays 
2.3  Selective  Highlighting 

6.1  Symbols  and  Symbol  Sets 

6.2  Standard  Terms 
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Threat  Resolution  Module 
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The  Threat  Resolution  Module  tracks  all  external  threats  and  determines 
appropriate  reactions  to  those  threats.  The  module  consists  of  five  separate 
processes:  Threat  Tracking,  Sensor  Cross-Correlation,  Age-In,  Age-Out,  and 
Reaction  Decision. 

THREAT  TRACKING  PROCESS 

Description 

The  Threat  Tracking  Process,  illustrated  in  Figure  18,  provides  a 
separate  routine  for  each  sensor.  It  updates  previously  entered  threats  and 
initiates  a  tracking  file  for  each  newly  identified  threat.  It  accepts 
sensor  data  from  the  Input/Output  Module  via  the  Data  Input  Buffers,  and  uses 
data  from  the  Threat  Priority  and  Threat  Tracking  Tables  and  from  the  Vehicle 
Data  File.  The  Threat  Tracking  Process  interfaces  directly  with  the  Sensor 
Cross-Correlation  and  Age-In  Processes  via  the  Threat  Tracking  Tables. 

Soldier-Machine  Interface  Implications 

This  process  does  not  by  itself  affect  the  soldier-machine  interface. 

Recommendations 

As  the  Threat  Tracking  Process  does  not  affect  the  operation  of  the 
interface,  no  guidelines  are  required. 
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Figure  18.  Schematic  of  System  Functions  Involving  the  Threat  Tracking 
Process  in  the  Threat  Resolution  Module 
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SENSOR  CROSS-CORRELATION  PROCESS 


Hie  Sensor  Cross-Correlation  Process,  shewn  schematically  in  Figure  19, 
provides  multiple  routines  that  correlate  threat  data  detected  by  the  dif¬ 
ferent  sensors  to  construct  multisensory  data  monitored  in  the  Threat 
Correlation  Files.  Hie  Sensor  Cross-Correlation  Process  is  requested  by  the 
Threat  Tracking  Process.  Its  purpose  is  to  determine  whether  sensor  cross¬ 
correlation  of  new  data  received  from  a  particular  sensor  is  appropriate,  and 
if  so,  to  update  previously  entered  data  or  to  enter  new  data  in  the  Threat 
Correlation  Files.  The  Sensor  Cross-Correlation  Process  uses  the  data  in 
the  Sensor  Cross- Correlation  Tables,  the  Threat  Priority  Tables,  and  the 
Vehicle  Data  File  which  are  updated  by  the  Configuration  Module,  the  Opera¬ 
tional  Test  Module,  and  the  Fault  Handling  Module.  The  Sensor  Cross- 
Correlation  Tables  are  threat  object  templates  containing  threat  identifica¬ 
tion  signal  types,  probabilities,  and  confidence  levels  which  merge  Threat 
Tracking  Files  into  multisensory  signal  input  correlation  files.  The  Sensor 
Cross-Correlation  Process  also  outputs  results  to  the  Prioritization  Module 
for  Process  Scheduling. 


Soldier-Machine  Interface  Implications 


The  data  gathered,  processed,  and  output  by  the  Sensor  Cross-Correlation 
Process  do  not  impact  the  soldier-machine  interface  as  part  of  the  Sensor 
Cross-Correlation  process.  This  process  updates  the  Threat  Correlation 
Files  with  data  that  ultimately  results  in  a  crew  message.  However,  this 
message  will  be  handled  through  the  Reaction  Management  Module . 


Recommendations 

As  the  Sensor  Cross -Cor relation  process  does  not  directly  impact  the  SMI, 
no  interfi.03  guidelines  are  applicable. 
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Figure  19.  Schematic  of  System  Functions  Involving  the  Sensor  Cross-Correlation 
Process  in  the  Threat  Resolution  Nodule 
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AGE- IN  PROCESS 


Description 

The  Age- In  Process,  shewn  schematically  in  Figure  20,  evaluates  the 
duration  and  consistency  of  tracked  threats  for  inclusion  in  (or  exclusion 
from)  the  Prioritized  Threat  List.  By  request  of  the  Threat  Tracking  Process 
and  the  Sensor  Cross-Correlation  Process,  it  functions  to  determine  whether 
their  output  into  the  Threat  Tracking  Tables  or  the  Threat  Correlation  Tables 
should  be  used  to  create  new  entries  or  to  update  existing  entries  in  the 
Prioritized  Threat  List  by  comparison  of  these  data  against  those  of  the 
Aging  Tables.  The  Aging  Tables  contain  duration,  frequency,  and  consistency 
parameters  for  each  threat  type  which  may  appear  in  the  Threat  Track  and  Threat 
Correlation  Files.  The  Age-In  Process  also  interfaces  directly  with  the 
Reaction  Decision  Process  via  the  Prioritized  Threat  List  and  with  Process 
Scheduling  via  the  Prioritization  Module. 

Soldier-Machine  Interface  Implications 

The  Age- In  Process  does  not  directly  affect  the  SMI.  The  data  it 
produces  can  conceivably  be  used  by  additional  processes  that  will  require  an 
SMI.  However,  the  Age-In  Process  does  not  require  an  SMI  to  accomplish  its 
processing. 

Recommendations 

As  the  Age-In  Process  does  not  impact  the  SMI,  no  interface  guidelines 
are  applicable. 
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Figure  20.  Schematic  of  System  Functions  Involving  the  Age-In  Process  in 
the  Threat  Resolution  Module 


AGE-OUT  PROCESS 


Description 

The  Age-Out  Process ,  illustrated  in  Figure  21 ,  determines  whether  the 
records  pertaining  to  tracked  threats  should  be  deleted  due  to  a  lack  of 
update  data  from  the  relevant  sensors.  The  Age-Out  Process  is  requested  by 
the  Prioritized  Threat  List  and  uses  the  Aging  Tables.  It  affects  all  other 
Threat  Resolution  processes  via  the  Prioritized  Threat  List,  the  Threat 
Correlation  Files,  and  the  Threat  Tracking  Files. 

Soldier-Machine  Interface  Implications 

The  Age-Out  Process  does  not  interact  with  the  SMI.  The  data  it  produces 
can  conceivably  be  used  by  additional  processes  that  will  require  a  SMI. 
However,  the  Age-Out  Process  does  not  require  an  SMI  to  accomplish  its 
processing . 

Recommendations 

As  the  Age-Out  Process  does  not  impact  the  SMI,  no  interface  guidelines 
are  applicable. 
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REACTION  DECISION  PROCESS 
Description 

The  Reaction  Decision  Process,  shorn)  schematically  in  Figure  22,  is 
requested  by  the  Age-In  Process  when  new  threat  data  are  available  from  the 
sensors.  Its  function  is  to  issue  an  appropriate  reaction  request  which 
accommodates  potential  conflicts  with  ongoing  reactions  and  to  the  availa¬ 
bility  of  reaction  resources  in  response  to  new  threat  data.  It  uses  data 
from  the  Prioritized  Threat  List  and  also  the  Peripheral  Status  File,  the 
Reaction  Decision  Tables,  and  the  Vehicle  Data  Files.  The  Peripheral  Status 
File  maintains  data  on  the  presence  and  operational  status  of  all  peripheral 
components ,  including  sensors,  countermeasure  devices,  crew  interaction 
devices,  and  the  communication  bus.  TOie  Reaction  Decision  Tables  contain 
lists  of  prioritized  reactions  and  priority  modification  values  for  each 
possible  threat  and  tactical  environment  condition.  The  Reaction  Decision 
Process  interfaces  directly  with  the  Reaction  Management  Module  via  the 
Reaction  Data  File. 

Soldier-Machine  Interface  Implications 

The  Reaction  Decision  Process  calls  the  Reaction  Management  Module  in 
the  event  threat  data  warrents  a  reaction  from  the  crew.  Any  interface 
implication  is  generated  through  that  module. 
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Recommendations 

As  the  Reaction  Decision  Process  does  not  impact  the  SMI,  no  interface 
guidelines  are  applicable. 
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Figure  22.  Schematic  of  System  Functions  Involving  the  Reaction  Decision 
Process  in  the  Threat  Resolution  Module 
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Reaction  Management  Module 


Description 

The  Reaction  Management  Module  shown  schematically  in  Figure  23  initiates, 
maintains,  and  suspends  countermeasure  actions  and  generates  information  and 
warnings  which  are  displayed  to  the  crew.  Its  purpose  is  to  resolve  conflicts 
between  reaction  preferences  presented  by  the  Reaction  Data  File  via  the 
Reaction  Decision  Process  and  those  indicated  by  the  crew  via  the  Control 
Panel  and  the  Control  Panel  Output  File  and  then  to  issue  commands  to  periph¬ 
eral  countermeasure  devices  and  to  crew  displays  accordingly. 

The  Reaction  Management  Module  is  requested  by  and  interacts  directly 
with  the  Age-In  Process  using  the  Prioritized  Threat  List.  It  uses  data  in  the 
Peripheral  Status  File  and  the  Vehicle  Data  File  which  are  updated  by  the 
Configuration  Module,  the  Operational  Test  Module,  and  the  Fault  Handling 
Module.  It  also  uses  data  from  the  Reaction  Data  File  which  is  input  through 
the  Reaction  Decision  Process  and  from  the  Control  Panel  Output  File  which  is 
input  by  the  crew  via  the  Control  Panel.  Output  of  the  Reaction  Management 
Module  is  to  the  Countermeasure  Activity  File  and  to  the  Tactical  Warning 
Display  File.  The  Tactical  Warning  Display  File  functions  through  the  Bus 
Data  Output  Process  of  the  Input/Output  Module  and  the  Output  Data  Buffers  to 
announce  the  resolution  of  any  conflict  between  the  threat  indications  of  the 
Reaction  Data  File  and  the  Control  Output  Data  File.  When  a  conflict  is 
resolved,  commands  are  issued  to  peripheral  countermeasure  devices  and 
warnings  are  issued  to  the  crew,  as  appropriate. 

Soldier-Machine  Interface  Implications 

During  combat  operations,  the  Reaction  Management  Module  probably  will 
generate  more  crew-system  interaction  than  all  other  modules  combined — and 
will  do  so  under  extremely  adverse  conditions.  Therefore,  this  module's 
interactions  with  the  crew  must  be  designed  with  the  utmost  care  to  provide 
rapid  completion  of  transactions  while  reducing  error  opportunities  to  a 
minimum. 
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Recommendations 


1.  The  Reaction  Management  Module  should  present  threat  warnings 
to  the  crew  via  graphics  displays  to  the  greatest  extent 
feasible.  Such  displays  should  include  a  map  overlay  showing 
the  location  of  the  VIDS-equipped  vehicle  and  relative  posi¬ 
tions  of  threats.  Threats  should  be  represented  by  easily 
recognized  symbols — which  may  require  research  to  identify. 
Guidelines  concerned  with  graphics  are  presented  in  the 
following  sections  of  the  Prototype  Handbook: 

2.2  Graphics  Displays 

2.3  Selective  Highlighting 

2.  Audio  displays  should  be  used  for  alerts  rather  than  for 
information  presentation.  That  is,  when  a  threat  warning  is 
displayed,  an  audible  alarm  presented  via  the  intercom  can 
be  used  to  draw  the  crew's  attention  to  the  display.  While 
this  alarm  could  be  a  simple  noise  such  as  a  buzz  or  bell,  a 
spoken  message  (e.g.,  "ENEMY  TANK  ON  THE  SCREEN")  would  be 
more  effective.  However,  because  the  vehicle  intercom  is  used 
for  other  purposes,  audio  messages  should  be  kept  short. 

3.  Crew  inputs  to  the  Reaction  Management  Module  may  be  feasible 
through  the  graphics  display  device,  for  example,  by  using  a 
touch-sensitive  surface  on  the  screen.  Depending  on  further 
analysis  of  the  module,  however,  alphanumeric  input  methods 
may  also  be  necessary.  Guidelines  appropriate  to  input  func¬ 
tions  are  contained  in  sections: 

1.1  Alphanumeric  Control  Methods 

1.2  Graphics  Control  Methods 

1 . 3  HELPS 

3.1  Information  on  Legal  Entries 

3.2  Unburdening  of  Input 

3.3  Interrupts  and  Work  Recovery 

4.1  Composition  Aids  for  Alphanumeric  Messages  (for  input) 

4.2  Composition  Aids  for  Graphics  Displays  (for  input) 

6.1  Symbols  and  Symbol  Sets 


6.2  Standard  Terms 


SUMMARY 


As  noted  above  under  "General  Findings,"  soldier-machine  interaction  with 
the  VIDS-DMS  will  differ  considerably  from  that  with  many  other  battlefield 
automated  systems.  First,  the  volume  of  transactions  will  be  lower,  in  that 
the  system  will  present  information  and  ask  for  crew  responses  primarily  on 
an  exception  basis.  The  crew  will  be  busy  with  other  tasks  required  to 
operate  the  vehicle,  and  will  have  little  time  for  VIDS-related  tasks  despite 
their  importance  (reaction  management  will  be  the  exception,  of  course) . 
Second,  while  minimal  demand  on  the  soldier's  intellectual  and  physical 
resources  is  typically  desirable  in  battlefield  automated  systems,  in  the 
VIDS-DMS  it  will  be  an  urgent  requirement.  The  purpose  of  the  system 
demands  that  meaningful,  understandable  information  be  presented  and  correct 
crew  responses  be  obtained  quickly.  Delays  caused  by  the  need  to  ponder  an 
ambiguous  output  or  to  deliberate  over  input  decisions  could  lead  to  the 
literal  destruction  of  the  vehicle  and  its  crew. 

For  all  these  reasons,  the  design  of  the  VIDS-DMS  will  be  critical  to 
optimum  operation  of  the  system  and  to  successful  performance  of  its  mission. 
System  messages  to  the  crew  must  be  brief,  fully  informative,  and  free  of 
redundancy  and  extraneous  detail .  Input  requirements  must  be  clear  to  the 
crew,  and  input  methods  must  permit  expeditious  command  and  data  entry.  To 
meet  these  requirements,  Synectics  has  recommended  the  transactional  features 
described  in  the  preceding  section  and  suggested  sections  of  the  Prototype 
Handbook  that  provide  guidance  appropriate  to  these  features.  Table  4 
summarizes  these  guideline  sections  by  module  and  process. 


Table  4.  Summary  of  Recommended  Guidelines  for  SMI  of 
VIDS-DMS  Modules  and  Processes 
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MODULE/PROCESS 


POWER  UP  MODULE 


PRIORITIZATION  MODULE 


CONFIGURATION  MODULE 


Initial  Configuration 


Failure  Reconfiguration 


Fault  Reconfiguration 


Tactical  Reconfiguration 


OPERATIONAL  TEST  MODULE 


Status  Check 


Self -Test 


FAULT  HANDLING  MODULE 


Bus  Hardware  Fault 


Status  Fault 


Data  Content  Fault 


INPUT/OUTPUT  FAULT 


Interrupt  Handler 
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